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1.0  INTRODUCTION 


1.1  BACKGROUND 

The  history  of  digital  computing  can  be  meaningfully  traced  for  some 
three  decades,  to  the  ENIAC  and  UNIVAC  I  systems  of  the  1940' s.  For  the 
first  half  of  that  period,  limitations  of  computer  hardware  were  the  primary 
constraint  on  the  application  of  digital  systems.  In  the  past  ten  to  fifteen 
years,  however,  hardware  technology  has  improved  to  the  point  where  software 
technology  has  become  the  limiting  factor.  The  tremendous  speed  and  com¬ 
putational  power  of  modern  computers  has  made  possible  very  complex  and 
sophisticated  systems.  The  software  imbedded  in  such  systems  provides  not 
only  the  mathematical  data  transformations  required,  but  also  provides  the 
control  functions  of  many  of  the  system  components  (such  as  radars)  and 
of  the  system  as  a  whole.  Therefore,  the  software  is  uniquely  critical  to 
the  successful  operation  and  performance  of  the  system. 

The  need  for  improving  the  techniques  of  designing,  building,  testing, 
and  managing  software  has  been  well  understood  for  several  years  and  has 
resulted  in  vigorous  research  and  development  within  the  Government,  indus¬ 
try,  and  the  universities.  This  has  led  to  the  development  of  improved 
programming  languages,  development  support  tools,  and  management  approaches, 
as  well  as  a  strong  theoretical  basis  in  such  areas  as  queueing  theory  and 
dynamic  programming  and  many  pragmatic  development  approaches  such  as  struc¬ 
tured  programming  and  top  down  design.  While  significant  improvements  have 
been  obtained  in  the  state-of-the-art  in  program  design,  implementation,  and 
testing,  much  additional  research  is  needed  and  is  being  actively  pursued  -- 
especially  in  such  areas  as  proof-of-correctness ,  data  base  design,  etc. 

There  is  an  additional  phase  of  software  development  which  is  especially 
critical:  the  definition  and  specification  of  the  functional  and  performance 
requirements  which  the  software  must  satisfy.  This  phase  is  especially 
critical  due  to  the  very  high  cost  and  schedule  leverage  which  exists.  Sim¬ 
ple  errors  In  the  requirements,  if  not  detected  until  after  the  software  has 
been  built,  are  extremely  expensive  in  terms  of  time  and  manpower  to  correct. 
While  it  has  been  apparent  for  quite  some  time  that  the  state-of-the-art  in 
developing  requirements  needed  improvement,  it  was  not  possible  to  accurately 
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identify  and  quantify  the  improvements  needed  until  after  the  design  imple¬ 
mentation,  and  test  phases  became  more  predictable  and  controlled.  Thus, 
in  the  fall  of  1973,  BMDATC  initiated  the  Software  Requirements  Engineering 
Program  with  the  objective  of  developing  a  set  of  tools  and  techniques  for 
defining  and  specifying  the  software  requirements  for  ballistic  missile 
defense  (BMD)  software.  The  result  of  that  research  Is  the  Software  Require¬ 
ments  Engineering  Methodology  (SREM)  which  Is  described  In  this  report. 

The  first  step  in  developing  the  Software  Requirements  Engineering 
Methodology  was  to  determine  the  properties  required  of  a  specification 
and  of  the  Individual  requirements  of  which  1*  is  composed.  Returning  to 
first  principles,  we  note  that: 

•  A  specification  Is  the  set  of  all  requlremetits  which  must 
be  satisfied,  and  the  Identification  of  the  subsets  which 
must  be  met  concurrently;  and 

•  A  specification  is  neither  legally  binding  nor  realizable 
unless  It  Is  consistent  with  both  the  laws  of  logic  and 
the  laws  of  nature. 

In  addition,  we  observe  that  f 

•  A  specification  defines  the  properties  required  of  a  product 
such  that  any  delivery  satisfying  the  specification  satisfies 
the  objectives  of  the  specifier. 

Taken  together,  the  above  truisms  lead  to  a  set  of  properties  which 
a  specification  must  have  from  a  technical  point  of  view: 

•  Internal  Consistency 

a  Consistency  with  the  physical  universe 

•  Freedom  from  ambiguity. 

Economic  and  management  considerations  lead  to  an  additional  set  of 
properties  which  a  good  specification  must  exhibit: 

a  Clarity 

a  Minimality 

a  Predictability  of  specification  development 

a  Controllability  of  software  development. 
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Since  freedom  from  ambiguity  is  mandatory,  we  naturally  looked  to  a 
machine-readable  statement  of  the  requirements.  It  is  a  known  principle 
of  computer  operation  that  input  ambiguities  can  be  tolerated  only  insofar 
as  they  are  designed  into  the  software.  Thus,  by  employing  an  unambiguous 
language,  and  by  translating  and  analyzing  it  with  a  program  intolerant  of 
ambiguity,  we  can  ensure  an  unambiguous  statement  of  requirements.  However, 
the  need  for  clarity  of  communication  strongly  suggests  a  language  resembling 
common  speech,  so  that  the  specification  can  be  read  by  managers,  systems 
engineers,  and  others  who  are  not  specially  trained  in  the  language. 

To  provide  an  internally  consistent  specification,  analyses  of  the 
requirements  statements  are  incorporated  into  the  system  supporting  the 
language.  These  analyses  include  semantic  and  syntactic  decomposition  of 
the  individual  statements,  and  analysis  of  the  composite  flow  of  data  and 
processing.  Support  of  consistency  with  the  physical  universe  is  accomplished 
by  converting  the  specification  unambiguously  into  a  model  (simulation) 
which  can  be  executed  against  a  model  of  the  real  world. 

Finally,  to  support  control  of  both  the  specification  process  and 
software  development,  a  means  of  selective  documentation  and  analysis  of 
the  specification  is  provided.  The  integration  of  these  tools  with  a 
sound  and  methodical  engineering  and  management  approach  provides  predict¬ 
ability  in  the  specification  process  and  aids  in  avoiding  overspecification. 

1.2  SCOPE  AND  CONTENT  OF  THIS  MANUAL 

This  manual  is  essentially  a  SREM  User's  Guide  for  development  of 
software  requirements  specifications.  It  is  not  a  cookbook,  in  that  it  does 
not  attempt  the  inherently  impossible  task  of  converting  the  genuinely 
creative  aspects  of  specification  development  into  rote,  deductive  opera¬ 
tions.  However,  it  does  define  guidelines  through  which  these  creative 
operations  are  recognized,  applied  and  restricted  to  their  natural  roles 
in  the  specification  development  process.  In  this  manner,  the  scale  and 
range  of  creativity  can  be  defined  and  contained,  thus  allowing  the  speci¬ 
fication  development  process  to  be  scheduled  with  some  degree  of  confidence. 

It  should  be  noted  that  creative  features  remain  in  the  methodology  and  as 
a  consequence  the  major  development  effort  must  be  conducted  by  experienced, 
knowledgable  engineers.  However,  SREM  has  been  structured  in  a  manner  such 
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that  many  elements  of  specification  development  can  be  identified  and 
isolated  to  permit  junior  engineering  personnel  to  perform  the  details 
of  specification  statement  definition  and  documentation  preparation. 

This  manual  is  organized  Into  two  parts:  Part  I  deals  with  the 
technical  aspects  of  software  requirements  engineering.  The  methodology 
Is  described  in  detail,  step-by-step,  in  the  context  of  an  example  begin¬ 
ning  In  Section  2.  Part  II  discusses  the  management  of  the  specification 
development  process  with  emphasis  on  how  the  specific  features  of  SREM  and 
its  tools  can  be  used  to  advantage  In  the  management  of  the  activities. 

This  document  is  intended  as  a  User's  Guide  for  the  requirements 
engineer.  It  describes  the  steps  of  the  Software  Requirements  Engineering 
Methodology  and  defines  the  techniques,  procedures  and  tools  to  be  used 
during  application  of  the  methodology  steps  to  the  development  of  a  Process 
Performance  Requirement  Specification.  The  language  (RSL)  and  tools  which 
form  the  Requirements  Engineering  and  Validation  System  (REVS)  are  described 
in  Reference  [1]  and  should  be  familiar  to  the  reader  prior  to  attempting 
to  apply  the  methodology. 

1.3  OVERVIEW  OF  SREM 

The  desired  properties  of  a  requirements  specification  discussed 
above  are  rather  general  in  nature.  These  can  be  precisely  defined  in 
terms  of  nine  characteristics  of  a  good  specification: 

•  Communicability  •  Traceability 

•  Testability  •  Correctness. 

•  Consistency  •  Design  Freedom 

•  Completeness  •  Flexibility  (Changeability) 

§  Feasibility 

These  characteristics,  which  are  self-explanatory,  formed  the  specific 
objectives  which  Influenced  every  aspect  of  the  development  of  SREM.  They 
are  repeated  here  to  establish  the  context  of  our  objectives.  Justification 
of  the  methodology  presented  here  against  these  goals  Is  contained  In  [2] 
and  will  not  be  repeated  here. 
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The  reader  who  wishes  to  learn  how  to  write  software  requirements 
using  the  SREM  techniques  should  first  study  the  language  and  support 
software  capabilities  described  in  the  REVS  Users  Manual  [1].  However, 
a  general  understanding  can  be  obtained  from  this  manual  alone.  To 
facilitate  this,  a  brief  overview  of  RSL  and  REVS  is  provided  here. 

1.3.1  The  Requirements  Statement  Language  (RSL) 

RSL  is  an  extensible  language  which  means  that  certain  primitive 
concepts  are  built  in  and  the  user  can  use  these  to  define  more  complex 
language  concepts.  The  primitives  are  elements,  attributes,  relationships, 
and  structures.  From  these,  we  have  defined  a  nucleus  of  concepts  which 
to  date  have  proven  sufficient.  Future  users  of  the  language  can  add  to 
these  by  means  of  the  extension  features  as  required.  These  concepts  are 
introduced  as  they  are  used  in  this  manual,  and  are  presented  in  full  in 
Appendix  A. 

The  Requirements  Statement  Language  is  a  user-oriented  mechanism  for 
specifying  requirements.  It  is  oriented  heavily  toward  colloquial  English, 
and  uses  nouns  for  elements  and  attributes  and  transitive  verbs  for  rela¬ 
tionships;  a  complementary  relationship  uses  the  passive  form  of  the  verb. 
Roth  syntax  and  semantics  echo  English  usage,  so  that  many  simple  RSL 
sentences  may  be  read  as  English  with  the  same  meaning.  However,  the 
precision  of  RSL,  enforced  through  machine  translation,  is  not  typical 
of  colloquial  speech;  as  a  result,  most  complex  RSL  sentences  are  a  some¬ 
what  stylized  form  of  English. 

1.3.2  The  Requirements  Engineering  and  Validation  System  (REVS) 

REVS  is  an  integrated  set  of  tools  used  to  support  the  definition, 
analysis,  simulation,  and  documentation  of  software  requirements.  A  key 
concept  of  REVS  is  that  all  requirements  are  translated  into  a  central 
data  base  called  the  Abstract  System  Semantic  Model  (ASSM).  The  RSL 
statements  themselves  are  not  stored  in  the  ASSM.  Instead,  they  are 
translated  into  representations  of  the  information  content  of  the  require¬ 
ments  statements.  This  provides  an  efficient  and  flexible  means  of  main¬ 
taining  a  large  software  specification  in  a  relatively  small  computer 
data  base. 
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The  ASSM  is  a  relational  data  base  providing  a  common  source  for  all 
requirements  analysis  and  modelling  and  for  documentation.  The  commonality 
of  all  data  ensures  that  any  combination  of  extractions  from  the  ASSM  at 
any  time  (e.g.,  a  document  and  a  simulation)  will  be  mutually  consistent. 
That  consistency  is  essential  .to  asserting  that  the  requirements  modelled 
in  validation  of  the  specification  are  equivalent  in  every  sense  to  those 
written  in  the  specification. 

REVS  provides  two  mechanisms  for  entry  of  data  into  the  ASSM,  trans¬ 
lation  and  interactive  graphics,  and  a  powerful  set  of  tools  for  analysis 
termed  collectively  Requirements  Analysis  and  Data  Extraction  (RADX) . 
Translation  is  the  process  of  converting  RSL  statements  into  the  ASSM 
information,  where  the  source  of  the  statements  may  be  cards,  card  images 
on  tape,  or  keyboard  entry  from  a  terminal.  Interactive  graphics  (RNET6EN) 
Is  a  software  package  executing  in  conjunction  with  the  the  Anagraph  color 
graphics  console  to  provide  ASSM  entry  and  illustrative  documentation. 

It  permits  entry  of  structures  and  referenced  elements  in  a  manner  parallel 
with  the  translator,  and  In  fact  may  be  used  in  conjunction  with  translation 
In  an  operational  environment.  Significantly,  RNETGEN  allows  the  user  to 
attribute  graphical  information  to  his  structure,  both  for  multicolor 
display  on  the  Anagraph  and  for  documentation  via  CALCOMP. 

Information  held  In  the  ASSM  may  be  selected  and  output  using  RADX. 
That  tool  is  responsive  to  user  direction  in  selecting  either  a  recreation 
of  the  Information  translated  into  the  ASSM,  or  the  formatted  abstraction 
of  that  information  in  a  user-defined  HIERARCHY.  The  combination  of  these 
features  allows  complex  selections  to  be  effected,  so  that  all  information 
needed  for  documentation  and  much  that  is  essential  to  configuration  manage¬ 
ment  can  be  abstracted  from  the  system  without  the  encumberance  of  Irrele¬ 
vant  data.  Since  all  data  abstractions  are  drawn  from  a  common  ASSM  (and 
since  that  data  base  is  confirmably  consistent  within  itself),  even  redun¬ 
dant  assertions  In  data  extractions  are  absolutely  consistent  with  one 
another. 

Both  static  and  dynamic  analysis  are  provided  by  REVS  in  order  to 
determine  the  Internal  consistency  of  the  ASSM  and  Its  validity  with 
respect  to  the  laws  of  nature.  Static  analysis  is  performed  in  RADX 
which  examines  the  data  connectivity  through  the  requirements  to  determine 
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that  the  laws  of  logic  and  the  conventions  of  the  language  are  fully 
satisfied  throughout.  Some  forms  of  completeness  testing  are  also  accom¬ 
plished,  determining,  for  example,  that  constants  are  provided  as  required; 
the  scope  of  completeness  testing  is  largely  at  the  discretion  of  the  user, 
since  he  may  define  extensive  static  analyses  through  RADX  commands  to 
supplement  those  inherent  in  the  system. 

No  amount  of  static  testing  can  fully  validate  a  set  of  requirements. 

To  do  so,  the  system  they  represent  must  be  exercised  against  a  model  of 
the  environment  in  which  the  system  is  to  execute.  Such  simulations  are 
provided  by  an  automated  simulation  builder  (SIMGEN),  and  a  software 
package  supporting  its  execution  (SIMXQT).  Two  different  levels  of  simu¬ 
lation  are  supported:  analytic,  in  which  high-fidelity  models  of  the 
environment  and  explicit  performance  measures  are  provided,  and  functional, 
in  which  the  connectivity  of  the  system  is  validated  with  non-analytic  models. 

1.3.3  The  Engineering  Methodology 

Historically,  the  methods  for  developing  a  software  specification 
have  been  as  numerous  as  the  developers  of  such  documents.  In  fact,  few 
cases  can  be  cited  in  which  any  formal  methodology  could  be  quoted.  Until 
the  specification  appeared  (often  after  tens  or  hundreds  of  man-years  of 
effort),  nothing  was  in  hand  to  show  that  it  would  be  generated.  In 
addition,  it  has  frequently  been  true  that  the  quality  of  the  specification 
even  with  respect  to  elementary  consistency  from  one  requirement  to  another, 
could  be  verified  only  very  late  in  software  development.  Since  the  prob¬ 
lems  were  discovered  only  when  the  cost  of  correction  was  prohibitive,  the 
requirements  were  frequently  changed,  degrading  system  performance  in 
order  to  have  some  workable  product. 

The  methodology  developed  within  SREP  is  not  only  formal,  in  that  it 
provides  an  explicit  sequence  of  steps  leading  to  the  specification,  but 
also  manageable,  in  that  it  illuminates  multiple  phases  for  management 
review  and  analysis.  Along  the  way,  it  supports  early  detection  of  high- 
level  anomalies,  since  it  works  from  the  highest  levels  of  software  defi¬ 
nition  (processing  and  data  flows)  to  the  most  detailed  (analytic  models 
and  data  content)  in  a  systematic  manner.  A  key  feature  of  SREM  is  that 
the  processing  functions  and  data  communications  are  considered  in  parallel, 


rather  than  have  either  follow  the  other.  As  a  result,  the  connectivity 
of  the  system  is  always  complete,  and  it  becomes  possible  to  partition  the 
requirements  effort  among  several  groups  early  in  the  process  without 
risking  divergence,  omissions,  or  inconsistencies. 

1.3.4  Specification  Management 

The  management  of  a  specification  developed  under  SREM  benefits 
most  from  the  common  source  in  the  ASSM  for  all  representations  of  the 
requirements.  Thus,  the  simulation  of  the  specification  and  the  documen¬ 
tation  of  its  requirements  must  be  consistent  at  any  time,  since  both 
have  a  single  source  of  data  which  generate  each  without  human  inter¬ 
vention.  In  addition  to  a  common  data  base,  the  methodology  itself 
supports  an  orderly  development  which  can  be  annotated  with  milestones, 
recorded  on  PERT  charts,  and  otherwise  controlled  with  the  tools  of  the 
last  several  decades  to  provide  predictability  and  control.  This  is  not 
to  suggest  that  the  creativity  of  the  specification  process  can  either  be 
scheduled  or  bypassed;  it  is  still  needed,  but  the  methodology  isolates 
it  into  segments  with  high  visibility,  supporting  management  cognizance 
of  its  progress  and  impact. 

1.4  APPLICABILITY 

These  tools  and  techniques  have  been  developed  to  address  the  needs 
of  BMD  software  development.  With  perhaps  minor  exceptions,  however, 

SREM  is  directly  applicable  to  the  specification  of  the  requirements  for 
any  central  software  process  for  a  large  real-time  system.  In  fact, 
since  the  methodology  is  inherently  and  deliberately  computer  independent, 
the  techniques  are  not  limited  strictly  to  software  in  the  form  of  com¬ 
puter  programs.  The  requirements  for  any  process  composed  of  logical 
decisions  and  computations  performed  on  data  can  be  expressed  via  SREM  -- 
regardless  of  whether  the  end  product  will  be  software,  hardware,  firm¬ 
ware,  or  some  combination  of  these. 

1.5  TERMINOLOGY 

At  the  risk  of  introducing  confusion,  we  have  introduced  soma  non¬ 
standard  terminology.  This  has  been  done  for  two  purposes:  (1)  to  emphasize 
the  different  interpretations  given  to  some  concepts,  and  (2)  to  emphasize 
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the  generality  of  the  methodology  application.  An  example  of  the  first 
is  the  use  of  the  term  ALPHA  for  a  processing  step.  The  more  common  term 
"function"  would  be  misleading  to  some  because  there  is,  in  fact,  a  wide 
variety  of  common  interpretations  of  "function".  To  avoid  misunderstanding, 
we  use  the  new,  unfamiliar  term  in  order  to  emphasize  its  specific  meaning. 
An  example  of  the  second  is  the  name  applied  to  the  resulting  requirements 
specification  which  we  call  the  Process  Performance  Requirements  (PPR). 

No  documentation  system  currently  in  use  recognizes  a  document  called  a 
PPR.  Here,  our  point  is  that  an^  software  requirements  specification, 
whether  called  a  B-5  (in  MIL-STD  490)  or  something  else  in  some  other 
system,  must  contain  a  certain  set  of  information.  That  set  of  information 
is  what  we  call  a  PPR. 

If  this  use  of  new  terminology  causes  confusion,  we  apologize. 

However,  once  the  techniques  are  understood,  they  can  be  applied  to  any 
program  and  the  terminology  adapted  to  the  needs  of  the  user. 
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PART  II  -  TECHNICAL  APPROACH 


2.0  SREM  OVERVIEW 

The  Software  Requirements  Engineering  Methodology  has  been  developed 
during  the  past  several  years  in  conjunction  witn  development  of  the 
Requirements  Engineering  and  Validation  System  and  as  a  consequence  has 
resulted  in  a  clean,  clear  and  comprehensible  compatibility  between  the 
methodology  and  the  instruments  it  uses  to  formulate  and  test  a  require¬ 
ments  specification.  While  REVS  embodies  the  language  and  tools  required 
for  orderly  development  of  process  requirements  specifications,  SREM 
defines  the  techniques  and  procedures  within  which  the  tools  and  sound 
engineering  and  management  practices  are  comLineci  to  generate  a  specifi¬ 
cation  containing  the  desired  properties  under  a  controlled  environment. 

SREM  encompasses  four  major  areas  of  engineering  activity  that  begin 
with  receipt  of  the  set  of  information  which  defines  the  system  level 
requirements  on  the  Data  Processing  Subsystem.  We  call  this  set  the 
Data  Processing  System  Performance  Requirements  Specification  (DPSPR). 

The  DPSPR  as  used  here  includes  the  Data  Processing  System  Interface 
Requirements  Specifications  and  any  external  subsystem  Performance  Require 
ments  Specifications  which  influence  the  definition  of  the  Process  Per¬ 
formance  Requirements.  Using  these  source  documents  as  a  stimulus,  the 
requirements  engineer  becomes  involved  in  the  four  major  engineering 
activities  defined  by  SREM  to  develop  the  Process  Performance  Reouire- 
ments  Specification.  These  engineering  activities  are: 


< 


Identification,  definition  and  development  of  the 
functional  requirements, 


Identification,  definition  and  development  of  the  performance 
requirements , 


Development  of  the  Process  Performance  Requirements  Speci¬ 
fication  and 


Development  of  the  process  design  feasibility  demonstrations 
which  are  generally  conducted  sequentially  and  separately. 
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The  inherently  sequential  nature  of  the  steps  of  the  methodology 
appeared  at  first  to  make  incremental  specification  of  software  awkward. 
Experience  on  many  programs,  notably  Systems  Technology  Program,  has  made 
it  clear  that  the  new  technology  should  assume  that  knowledge  of  require¬ 
ments  will  increase  continuously  throughout  the  development  of  the  software 
specification,  rather  than  be  complete  when  software  requirements  are  first 
initiated.  Thus,  the  tools  and  methodology  of  SREP  were  developed  to 
allow  for  incremental  development  of  the  specification.  Specific  features, 
such  as  VERSION  and  the  qualified  inclusion  of  RJiETs  in  a  simulation 
provide  the  capability  either  for  defining  segments  of  the  software  require¬ 
ments  at  a  time,  or  for  augmenting  a  full  subsystem  with  additional  func¬ 
tions.  The  consistency  and  integrity  enforced  by  the  system  are  fundamental 
to  success  in  incremental  specification.  They  ensure  that: 

•  Portions  of  the  system  specified  later  than  some  segments 
will  be  consistent  since  their  connectivity  with  the  early 
segments  was  defined  at  the  highest  levels;  and 

•  Any  extension  of  the  system  will  be  compatible  with  prior 
specification,  since  any  inconsistency  would  preclude 
entering  the  extension  into  the  ASSM. 

During  each  activity  of  SREM  the  features  of  REVS  are  utilized  to 
control,  monitor,  test  and  maintain  the  evolving  collection  of  requirements 
statements.  The  functional  requirements  are  defined  in  RSL  statements  and 
catalogued  by  REVS  in  the  ASSM  through  the  TRANSLATOR  segment.  The  accuracy 
and  correctness  of  these  RSL  statements  is  verified  by  the  Static  Analyzer 
portion  of  the  RADX  segment  of  REVS.  Continuity  and  completeness  of  these 
RSL  statements  is  analyzed  through  the  SIMGEN  and  simulation  execution 
segments  of  REVS  using  algorithms  for  each  functional  requirement  repre¬ 
sented  as  executable  PASCAL  procedures  implemented  as  BETA  models.  Next, 
the  performance  requirements  are  defined  in  RSL  statements  and  catalogued 
by  REVS  in  the  ASSM  through  the  TRANSLATOR  and  attached  to  the  functional 

requirements  each  CONSTRAINS.  The  accuracy  and  correctness  of  these  RSL 
statements  is  again  verified  by  the  Static  Analyzer  portion  of  the  RADX 
segment  of  REVS.  Continuity  and  completeness  of  these  RSL  statements  is 
analyzed  through  the  SIMGEN  and  simulation  execution  segments  of  REVS 
using  algorithms  for  each  functional  requirements,  represented  as  executable 
PASCAL  procedures  implemented  as  GAMMA  models.  Validation  of  the  func- 


tional  and  performance  requirements  testability  is  confirmed  by  REVS  through 
the  Post-Processing  Analyzer  using  executable  PASCAL  procedures  implemented 
as  EXTRACTOR  and  TEST  models.  In  this  way,  the  existence  of  a  feasible 
design  solution  for  the  collection  of  functional  and  performance  require¬ 
ments  statements  is  confirmed  by  REVS  through  use  of  candidate  algorithms 
used  as  the  GAMMA  models,  and  a  model  of  the  system  environment  and  threat 
(SETS).  The  models  are  executed  against  one  another  with  a  variety  of 
scenarios  to  demonstrate  the  existence  of  a  solution  to  the  requirements 
statement  in  the  ASSM.  Finally,  data  collected  through  RADX  are  formated 
and  published  as  a  Process  Performance  Requirements  Specification. 

The  preceding  information  has  been  provided  to  introduce  and  orient 
the  reader  to  the  global  view  of  SREM  and  the  REVS  instruments  used  in  the 
methodology  to  create  a  PPR,  and  to  validate  it  through  automated  simulation. 

The  detailed  description  of  the  SREM  technique  of  specifying  software 
functional  and  performance  requirements  is  presented  in  Sections  3  and  4. 

The  methodology  is  described  in  the  context  of  an  example  which  is  worked 
out  to  the  degree  necessary  to  illustrate  the  method.  The  example  is  a 
hypothetical  system  called  Track  Loop  System  (TLS).  TLS  is  representative 
of  the  kind  and  complexity  of  real  BMD  systems,  and  yet  is  simple  enough 
to  serve  as  a  comprehendible  example.  A  complete  DPSPR  (including  the 
interface  specifications)  for  TLS  is  provided  as  Appendix  F.  The  system 
is  summarized  below. 

2.1  THE  TRACK  LOOP  SYSTEM  EXAMPLE 

The  Track  Loop  System  (TLS)  is  a  subset  of  a  Preliminary  Ballistic 
Missile  Defense  System  that  is  capable  of  nearly  autonomous  execution  in 
response  to  external  stimuli.  It  is  the  simplest  known  subsystem  with 
properties  of  interest  for  software  definition,  and  it  is  one  which  has 
been  studied  extensively,  both  in  the  academic  literature  and  in  such 

practical  programs  as  Site  Defense.  Therefore,  it  has  been  selected  as 
the  testbed  for  supporting  experimentation  in  development  of  the  methodology 
for  software  requirements.  A  pictorial  representation  of  the  TLS  is  pro¬ 
vided  in  Figure  2-1. 
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A  Preliminary  Ballistic  Missile  Defense  System  (PBMDS)  has  been 
postulated  as  an  environment  in  which  the  TLS  would  execute.  It  is  a 
generalized  representative  of  the  class  of  systems  currently  in  develop¬ 
ment,  and  is  particularized  foi  the  TLS  through  representative  but  non- 
real  specifications  where  required.  In  the  Conduct  Engagement  mode,  an 
object  entering  the  search  region  will  be  detected  and  designated,  tracked, 
discriminated,  and  engaged  (as  required)  in  defense  of  the  ground  facilities. 
Those  functions  are  implemented  through  the  Data  Processing  System  (DPS), 
a  radar  or  other  sensor,  and  a  means  of  neutralizing  hostile  objects.  For 
the  purpose  of  the  TLS,  only  the  radar  need  be  defined  in  detail;  other 
system  elements  are  identified  only  to  the  extent  that  they  impact  DPS 
requi rements . 

2.1.2  TLS  Requirements 

The  TLS  is  required  to  perform  five  system  level  functions:  1)  system 
initialization  and  engagement  initiation,  2)  engagement  termination,  3)  tar¬ 
get  tracking,  4)  control  of  system  resources  and  5)  recording  of  data  during 
the  engagement.  The  system  includes:  the  DPS,  the  Radar  and  the  recording 
media  and  directly  interfaces  with  the  external  environment  through  commu- 
nications  and  control  (C  ). 

? 

In  general,  the  functions  of  TLS  are  initiated  by  messages  from  C'; 

however,  track  maintenance  and  certain  control  functions  are  autonomous. 

2 

The  engagement  is  initiated  and  terminated  by  C  messages;  during  engagement, 

radar  data  are  reported  periodically  autonomously.  When  an  image  is  handed 

2 

over  to  TLS  through  C  ,  it  is  tracked  without  further  direction,  until  it 
is  dropped  either  by  command  or  by  determination  within  the  DPS.  This 
configuration  thus  demonstrates  both  exogenous  and  endogenous  process 
excitation,  and  in  other  ways  provides  a  microcosm  of  a  BMD  process. 


2.2  SUMMARY  OF  APPENDICES 

The  Appendices  provide  a  summary  of  the  Requirements  Statement 
Language  and  a  complete  development  of  the  TLS  requirements  statements. 
A  complete  description  of  RSL  is  provided  in  the  REVS  Users  Manual 
(Reference  [1]). 


Appendix  A  summarizes  the  RSL  Terminology  by  providing  a  copy  of 
the  RSL  nucleus  which  defines  each  element  of  the  language  and  an  illus¬ 
tration  of  the  symbology.  Appendix  B  contains  the  set  of  hand-drawn 
representations  of  TLS  requirements  which  correspond  to  the  results  ob¬ 
tained  from  application  of  the  methodology  defined  in  Section  3.1.  Appen¬ 
dix  C  represents  the  TLS  kernel  which  contains  the  flow  and  data  hierarchies 
developed  as  a  result  of  the  methodology  defined  in  Section  3.2.  Appendix 
D  presents  the  set  of  R_NETs  and  the  SUBNET  produced  by  the  Cal  comp  capa¬ 
bility  of  the  interactive  graphics  segment  of  REVS.  Appendix  F  represents 
the  complete  TLS  Data  Base  maintained  in  the  ASSM  as  extracted  by  the  RADX 
segment  of  REVS.  Appendix  F  contains  the  TLS  source  specifications  from 
which  the  TLS  requirements  were  developed. 

Appendices  C  through  E  have  been  produced  by  REVS  from  the  ASSM  in 
much  the  same  manner  that  the  information  content  of  a  software  specifica¬ 
tion  would  be  developed.  Editing  of  this  Information  into  a  specification 
document  would  be  adapted  to  the  particular  needs  of  a  specific  program. 

A  sample  PPR  specification  was  produced  in  Reference  [2]  and  the  review  It 
elicited  has  underscored  the  need  for  adaptation  of  the  extracted  infor¬ 
mation  to  the  specifics  of  an  application.  Therefore,  neither  REVS  nor 
SREM  Is  designed  to  produce  a  specific  specification  format.  This  simple 
final  step  is  left  to  the  discretion  of  the  user. 
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3.0  FUNCTIONAL  REQUIREMENTS 

It  i:  possible  and  practical  to  view  a  software  requirement  as  de¬ 
fining  either  what  must  be  accomplished  or  how  well  it  must  be  done.  The 
former  is  termed  a  "functional  requirement",  since  it  specifies  data  process¬ 
ing  functions;  the  latter  is  termed  a  "performance  requirement"  since  it 
constrains  the  quality  of  performance  of  the  function  in  the  system.  In 
another  sense,  it  is  useful  to  look  upon  the  functional  requirement  as 
defining  the  required  output  in  terms  of  the  available  inputs.  In  a  si~p1c 
case,  a  program  might  be  named  SUMMER  and  have  a  functional  requirement  of 
generating  the  sum  of  a  sequence  of  input  numbers  (X^).  Defining  the  output 
after  i  inputs  to  be  ,  tf;e  performance  requirement  might  be  that  (Yi+-j  - 
Y.. )  be  within  e  of  . 

Note  that  while  the  functional  requirement  specifies  what  is  to  be  done, 
and  the  performance  requirement  constrains  how  well  it  must  be  accomplished, 
the  means  of  accomplishment  is  left  to  process  design;  since  the  means  of 
implementation  is  not  specified,  the  requirements  are  said  to  be  design-free. 

The  form  of  representation  of  functional  requirements  has  evolved  in 
recent  years,  end  has  culminated  in  Requirements  Networks  (R-Nets).  Origi¬ 
nally,  verbal  descriptions  of  functions  were  attempted,  but  the  verbiage  was 
found  to  be  cumbersome  and  ambiguous.  Later,  througn  Engagement  Logic  and 
Functional  Flow  Block  Diagrams  (FFBD's),  diagrams  replaced  many  words  (the 
pictures  being  worth  thousands  of  words  apiece).  Unfortunately,  much  of  the 
ambiguity  was  retained.  Notably,  it  was  difficult  in  practice  to  trace  re¬ 
quired  processing  paths;  data  definitions  were  incomplete;  and  the  mechanism 
did  not  lend  itself  to  consistency  or  completeness  analysis. 

To  avoid  the  problem  of  recognizing  processing  paths,  a  thread  de¬ 
scription  was  attempted;  unfortunately,  the  number  of  threads  in  a  real 
system  proved  so  large  that  the  (essentially  one-dimensional)  representa¬ 
tion  was  almost  as  hard  to  use  as  English  text.  Conversion  to  thread  trees 
somewhat  reduced  the  magnitude  of  the  thread  problem,  but  left  the  other 
difficulties  of  undesired  specificity  (in  AND  branches),  ambiguity  (espe¬ 
cially  in  data),  and  awkwardness  for  analysis. 
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The  properties  preserved  in  defining  R-Nets  were: 

•  graphic  representation  of  functional  requirements; 

•  path  orientation  for  specification  of  threads; 

•  design  (implementation)  independence. 

In  addition,  the  use  of  R-Nets  permitted  the  addition  of  the  following 
properti es: 

•  unambiguous  statement; 

•  analyzable  models; 

•  explicit  data  specification. 

In  effect,  those  six  properties  became  the  top-level  specification  of  the 
tools  and  methodology  of  the  SREM  functional  specification. 

It  is  significant  the  properties  carried  over  from  previous  means 
of  statement  are  those  relating  to  subjective  measures  of  legibility,  util¬ 
ity  and  design  freedom.  The  added  properties  are  objectively  assessable  - 
most  readily  by  demonstration.  Thus,  a  part  of  the  program  has  been 
the  demonstration  of  completeness,  freedom  from  ambiguity,  and  other  attri¬ 
butes  through  static  analyzers  of  the  explicit  (machine-readable)  Require¬ 
ments  Statement  Language  (RSL) .  By  expressing  the  functional  requirements 
in  machine- readable  form,  and  by  using  the  tools  developed  on  a  variety  of 
programs  In  both  industry  and  academia,  it  is  possible  to  generate  an  ulti¬ 
mate  test  of  a  functional  specification  -  a  functional  simulation. 

A  simulator  built  without  human  intervention  from  a  specification  is 
a  total  demonstration  of  the  consistency,  precision,  and  completeness  (In 
at  least  a  limited  sense)  of  that  specification.  With  a  suitable  driver, 
such  a  simulation  provides  a  useful  tool  for  defining  frequency  of  transac¬ 
tion  and  examining  the  gross  aspects  of  system  tradeoffs. 

Fundamentally,  there  are  three  different  ways  of  conceiving  of  soft¬ 
ware  requirements.  The  classical  approach  is  functional:  what  operations 
are  to  be  performed  by  the  system  logic,  as  embodied  in  the  software.  A 
thread  approach  Is  more  nearly  mechanical:  what  are  the  interfaces  and  the 
properties  of  the  messages  required  to  be  communicated  through  them.  The 
third  concept  may  be  termed  philosophical:  what  are  the  realities  of  the 
world  the  DPS  perceives,  and  what  information  about  those  realities  must  be 
manipulated.  Clearly,  each  approach  can  lead  to  machanlsms  by  which 
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requirements  may  be  generated;  SREM  uses  all  three  concurrently. 

The  functional  approach  is  embodied  in  the  concept  of  a  Requirements 
Network  (N-Net),  which  defines  the  processing  flow  required  of  the  software. 
The  mechanical  concepts  are  reflected  in  the  heavy  dependence  of  SREM  on 
definitions  of  messages  through  interfaces  in  establishing  the  top  level 
of  data  hierarchies,  and  philosophy  is  preserved  in  the  implementation- 
independent  hierarchies  defined  under  entities.  The  three  viewpoints  are 
merged  in  the  simulation-level  definitions  of  requirements  as  data  and 
executable  descriptions;  the  interrelationships  of  the  three  points  of 
view  are  realized  in  the  simulation  itself.  Sections  3.1  and  3.2  provide 
the  methodology  for  generating  the  highest  level  of  requirement  from  each 
perspective,  3.3  carries  the  definition  to  the  next  level  and  begins  to 
interrelate  them  through  RSL  statements,  and  3.4  completes  the  methodology 
for  their  realization  in  the  executable  description.  Sections  3.5  and  3.6 
suggest  the  means  for  adding  descriptive  and  supportive  information  to 
support  specification  management  and  documentation.  Section  3.7  extends 
the  methodology  into  analytic  modelling. 

3.1  PHASE  1  -  DEFINITION  OF  SUBSYSTEM  ELEMENTS 

There  are  two  different  "structural"  elements  to  be  defined  in  the 
first  stage  of  functional  specification.  One  is  the  flow  connectivity 
previously  represented  with  Engagement  Logic  or  FFBD's.  The  other  is  new 
with  the  current  methodology,  and  defines  the  data  hierarchies  required. 
Previously,  there  was  no  specific  methodology  even  for  the  definition  of 
flow  connectivity;  the  approach  used  was  often  to  lock  an  appropriate  num¬ 
ber  (typically  3)  of  the  "right  people"  in  a  room  for  a  few  weeks,  and  watch 
the  product  appear.  By  adding  the  data  hierarchy  to  the  structures,  we  have 
been  able  to  identify  a  step-by-step  mechanism  for  the  top-level  development, 
in  which  only  the  areas  requiring  creativity  are  left  uncontrolled,  and 
those  areas  are  clearly  identified. 

The  first- time  SREM  user  may  find  that  he  has  to  reorient  his  thought 
processes  in  order  to  effectively  use  the  methodology  and  the  REVS  software. 
In  time,  he  will  find  that  the  steps  herein  form  a  natural  progression  for 
the  job  to  be  done.  He  should  always  keep  in  mind  that  his  job  is  to  develop 
the  requirements  for  software,  and  not  to  design  the  software  itself.  He 
should  constantly  ask  himself,  "How  can  I  precisely  state  what  the  DPS  is 
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required  to  do  in  the  most  general  way,  so  that  the  designer  has  the  maximum 
range  of  choice  in  deriving  the  solution?" 

A  typical  specification  process  usually  starts  with  a  notion  of  the 
processing  steps  involved  and  later  considers  the  data  needed  to  support 
that  processing.  SREM  partially  reverses  this  order  of  consideration.  The 
user  must  first  ask  two  questions:  1)  "What  data  are  presented  to  the  DPS 
for  processing?",  and  2)  "What  data  are  expected  from  the  DPS  as  output?" 

From  the  answers  to  these  questions,  the  user  derives  his  concepts  of  the 
processing  steps  in  between. 

It  is  suggested  that  the  user  accomplish  the  work  at  each  step 
across  the  breadth  of  the  project  before  proceeding  to  the  next  step.  In 
large  projects,  involving  many  people,  the  needs  of  communication  and 
coordination  make  this  mandatory.  In  smaller  projects,  especially  those 
involving  one  or  two  people,  there  is  often  a  rush  to  do  all  the  steps 
for  one  small  area  of  the  system  before  considering  the  next  area  of 
concern.  This  may  be  possible  for  a  DPS  problem  where  the  processing 
functions  are  independent,  but,  at  best,  many  valuable  insights  into  the 
required  operation  of  the  DPS  as  a  whole  may  be  lost.  At  worst,  a  signif¬ 
icant  amount  of  rework  may  be  Involved. 

3.1.1  Initial  Inputs 

The  initial  inputs  required  for  application  of  SREM  are,  typically,  a 
system  specification  and  its  companion  interface  specifications.  The  objec¬ 
tive  is  to  generate  a  complete  specification  for  ti.v;  data  processing  sub¬ 
system  (DPS)  from  these  basic  inputs.  Usually,  at  this  early  stage  of  sys¬ 
tem  development  the  input  specifications  are  incomplete,  contain  many  ambi¬ 
guities,  and  leave  several  issues  for  future  resolution.  The  SREM  user  need 
not  wait  for  all  gaps  to  be  filled.  Instead,  the  user  should  proceed  from 
that  which  is  clearly  defined,  and  use  the  facilities  of  the  RSL  management 
segment  to  spotlight  issues  needing  resolution.  Assumptions  and  decisions 
may  be  necessary,  often  based  on  inadequate  data.  The  SREM  user  should  not 
avoid  these,  but  should  note  them  in  the  ASSM  using  the  RSL  element  DECISION 
and  its  attributes.  The  important  thing  is  to  make  these  entries  as  they  arise. 
In  this  way  the  SREM  user  not  only  leaves  a  traceable  record  of  current 
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status  for  others,  but  leaves  a  valuable  record  of  the  evolution  of  his 
thoughts  about  the  subsystem  for  his  own  future  reference. 

3.1.2  Interface  Definition 

The  first  RSL  entries  in  the  ASSM  are  concerned  with  identification 
of  the  DPS  interfaces  which  CONNECT  with  other  subsystems.  Usually,  these 
are  the  elements  which  are  most  clearly  defined  in  the  originating  speci¬ 
fications.  Also,  it  has  been  found  that  the  interfaces,  and  the  messages 
passing  through  them,  are  the  key  focal  points  for  progressive  development 
of  the  requirements  structure. 

Consider  the  TLS  specification  (DPSPR)  and  interface  specifications 
(IFSs)  contained  in  Appendix  F„  These  documents  refer  to  two  subsystems 
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which  interface  with  the  DPS,  namely  the  Radar  and  the  C  (Command  and 

2 

Communications).  We  will  refer  to  C  as  a  subsystem  for  convenience,  even 
though  it  is  a  separate  system,  external  to  the  TLS.  A  closer  examination 
of  the  DPSPR  reveals  that  the  DPS  is  to  output  data  to  permanent  files. 
Although  not  explicitly  required  by  the  specification  it  will  later  become 
apparent  that  it  is  conceptually  useful  to  define  permanent  storage  as  a 
third  subsystem  separate  from  the  DPS,  even  though  it  is  embedded  in  the 
DPS.  For  REVS  use  we  will  name  the  three  subsystems  SSRADAR,  SSC2,  and 
SSPERMFL,  respectively. 

In  the  specifications,  three  separate  interfaces  between  the  DPS  and 
the  radar  are  mentioned.  Through  one  input  interface  the  radar  sends  re¬ 
turns  to  the  DPS;  through  another  it  sends  clock  inputs  to  the  DPS.  The 
DPS  issues  commands  to  the  radar  through  an  output  interface.  We  will  name 
these  interfaces  RADAR_IN,  RADAR_CLOCK_IN,  and  RADAR_0UT,  respectively.  The 
names  are  arbitrary,  but  should  be  meaningfully  related  to  the  specification 
terminology.  Note  that  an  interface  is  designated  as  "input"  or  "output" 
from  the  viewpoint  of  the  DPS. 

2 

Similarly,  the  specifications  call  out  one  input  interface  between  C 

and  DPS.  We  will  call  this  input  interface  CC _ I N .  Data  recorded  by  the  DPS 

in  permanent  storage  apparently  are  never  accessed  from  that  source  during 
DPS  operation.  Therefore,  we  will  link  the  DPS  to  our  conceptual  subsystem 
SSPERMFL  via  an  output  interface,  DATA_RECORD. 
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At  this  point,  the  subsystem  and  interface  definitions,  and  their 
relationships,  can  be  coded  in  RSL  for  entry  Into  the  ASSM.  Figure  3-1 
shows  one  way  of  expressing  these  data  in  RSL.  Note  that  the  management 
segment  attribute,  DESCRIPTION,  has  been  used  to  explain  the  nature  of 
SSPERMFL.  This  entry  is  for  example  purposes  here,  and  will  not  be  per¬ 
petuated  in  the  TLS  example.  However,  notations  such  as  this  have  value 
in  a  real  system  development  project  and  should  be  encouraged. 

Note  that  the  DPS  itself  is  not  entered  into  the  ASSM  as  a  SUBSYSTEM, 
since  it  is  inherently  the  object  of  all  software  requirements. 

3.1.3  Message  Definition 

Having  defined  the  subsystems,  the  interfaces,  and  their  connections, 
the  next  logical  step  is  to  examine  the  discrete  blocks  of  data,  or  MESSAGES 
which  are  PASSED  BY  the  interfaces.  A  MESSAGE  is  MADE  BY  its  contents, 
whether  they  be  DATA  or  FILEs. 

One  must  be  careful  to  separate  the  concepts  of  "message  name"  or 
"message  category"  from  that  of  "message  type".  In  RSL,  the  identifier 
associated  with  MESSAGE  refers  to  the  message  name  or  category.  MESSAGES 
are  distinguished  by  differences  in  their  data  contents.  Thus,  two  blocks 
of  data  with  different  data  contents,  which  pass  through  an  interface, 
must  be  defined  as  different  MESSAGES,  hence  must  have  different  message 
names.  The  message  name  is  not  contained  in  the  data,  it  is  an  external  label. 

On  the  other  hand,  two  packets  of  data  may  have  identical  data  con¬ 
tent  with  different  values,  and  may  require  different  processing  to  be 
done  on  the  data,  within  the  DPS.  In  this  case  one  would  have  two  Instances 
of  the  same  MESSAGE,  but  with  different  "message  type".  One  would  further 
expect  that  one  of  the  data  elements  in  the  message  would  be  a  message  type 
identifier,  with  a  unique  value  for  each  type.  Otherwise,  the  DPS  could 
not  distinguish  between  types  of  messages  and  perform  different  processing 
operations  on  each  type.  Messages  with  different  names  must  also  have  a 
unique  identifier  in  order  for  the  DPS  to  distinguish  between  messages.  It 
Is  most  economical  to  require  that  all  messages,  whether  of  different  name 
or  type,  contain  a  type  identifier  as  a  data  element,  with  a  unique  value, 
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SUBSYSTEM:  SSPAOAP. 
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SUBSYSTEM:  SSPFRMFL. 
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DFFCR IPTION :  "SSPIRmfL*  ALTHOUGH  CONTAINED  IN  THE  DPS* 

IS  OF  FI NED  HERE  AS  A  SUBSYSTEM  F  OR  CONVENIENCE 
IN  EXPLANATION  AND  SIMULATION.*. 
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first  branch  point.  Data  elements  unique  to  a  specific  message  are  placed 
on  the  branch  unique  to  that  message.  Elements  common  to  two  or  more  mes¬ 
sages,  but  excluded  from  others,  are  placed  on  an  Intermediate  branch  lead¬ 
ing  only  to  the  appropriate  messages.  (The  TLS  example  discussed  below  will 
illustrate  this  latter  condition.)  The  data  element  names  may  refer  to  data 
items,  or  files.  It  is  useful  to  note  files  as  such  on  the  diagram.  A 
file  is  a  collection  of  instances  of  data  items  each  instance  having  the 
same  structure.  If  desired,  the  SREM  user  can  note  the  types  of  each 
message  below  the  message  name.  While  the  diagram  format  shown  has  proven 
useful,  it  is  in  no  way  mandatory.  The  user  is  encouraged  to  adopt  what¬ 
ever  notation  or  format  aids  him.  The  Important  point  Is:  organize  the 
material  on  paper  before  writing  the  RSL  inputs. 

A  useful  rule-of-thumb  for  using  SREM  is:  don't  define  details  until 
they  are  needed  for  the  purposes  of  the  moment.  At  thi.  stage  of  our  analy¬ 
sis,  we  are  interested  solely  in  the  elements  which  are  common  to,  and 
unique  to  the  various  message  types.  No  further  detail  is  needed.  For 
instance,  if  it  is  known  that  an  identifiable  group  of  data  is  unique  to 
a  given  message,  it  is  only  necessary  to  name  the  group  as  a  data  item  on 
the  tree.  In  practice  this  is  often  easy,  because  the  exact  composition 
of  the  group  may  be  ambiguous  long  after  the  group  Itself  Is  Identified, 

In  any  case,  the  composition  of  a  group  is  easily  defined  by  the  RSL  rela¬ 
tion  INCLUDES  when  that  level  of  detail  is  needed. 

Now,  let  us  consider  the  messages  in  the  TLS  example,  starting  with 
those  coming  from  the  C2  "subsystem".  Paragraph  3.2  of  the  TLS  C2/DPS  IFS 
states  that  four  types  of  messages  are  transmitted  from  the  C  to  the  DPS: 

•  Initiate  Engagement  Mode 

•  Terminate  Engagement  Mode 

•  Handover  Image 

•  Drop  Image  Track 

Implicitly  common  to  all  these  message  types  Is  some  sort  of  message 
type  identifier.  Since  these  are  all  common  messages  we  will  call  this 
Identifier  COMMANDED.  Paragraphs  3.<:.1  and  3.2.2  of  the  IFS  imply  that 
there  are  no  other  data  elements  in  the  first  two  message  types.  Both  of 
these  types  have  a  common  function,  namely  to  command  a  change  in  the 
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operating  mode  of  the  DPS.  Thus,  they  form  a  single  MESSAGE  category 
which  we  will  name  MQDEjCHANGE.  Hence,  as  shown  in  the  diagram  of  Figure 
3-3  ,  we  have  a  message  MODEjCHANGE,  of  two  types,  with  a  single  data  ele¬ 
ment,  COMMANDED,  which  distinguishes  the  two  types. 

The  remaining  two  message  types  contain  other  data  elements,  in  addi¬ 
tion  to  COMMANDED,  as  stated  in  paragraphs  3.2.3  and  3.2.4.  Common  to 
both  is  an  element  called  variously  "Image  designation",  or  "image  desig¬ 
nator1',  but  which  is  obviously  a  single  element  which  we  will  call  H0_ID 

(shortened  from  HANDOVER _ ID) .  This  additional  element  completes  the  defi‘- 

nition  of  the  "Drop  Image  Track"  type  message.  Since  the  data  content  of 
this  message  Is  unique.  It  forms  a  message  category  by  itself.  We  will 
name  this  message  TERMINATION  because  we  wish  to  reserve  DROP_TRACK  for  use 
as  an  enumerated  value  of  COMMANDED. 

The  remaining  message  type  is  also  in  a  category  by  itself,  which  we 
will  name  a  HANDOVER  message.  In  addition  to  COMMANDED  and  H0_ID,  para¬ 
graph  3.2.3  of  the  IFS  states  that  this  message  contains  a  data  element 
"image  estimated  state".  However,  paragraph  1.1.2.1a  of  the  DPSPR  refers 
to  an  "estimate  of  state",  while  paragraph  1.2.2.1g  states  that  "each 
handoff  shall  consist  of  a  unique  designator,  the  state  vector,  and  its 
covariance  matrix."  At  this  point  we  could  be  content  with  defining  the 
data  element  as  INITIAL_STATE_ESTIMATE.  But,  it  seems  worthwhile  to  state 
the  main  components,  since  they  are  not  stated  in  the  IFS  paragraph  where 
one  would  expect  to  find  them.  Thus,  we  define  two  data  elements,  INITI AL_ 
STATE  and  INITIALjCOVARIANCE,  to  represent  the  vector  and  matrix,  respec¬ 
tively.  The  prefix  "Initial"  is  used  to  avoid  confusion  with  state  data 
generated  by  the  DPS  in  the  course  of  subsequent  processing.  Note  that 
there  Is  no  need,  at  this  point,  to  define  the  vector  components  and  ma¬ 
trix  elements  individually.  We  have  now  completed,  apparently,  the  defi¬ 
nition  of  messages  related  to  the  CC_IN  interface,  as  shown  in  Figure  3-3. 
These  messages  can  be  defined  in  RSL  as  shewn  in  Figure  3-4.  Although  not 
shown  here,  it  Is  useful  to  use  the  capabilities  of  the  management  segment 
of  RSL  to  note  the  source  of  the  state  data  definitions  in  the  handover 
message,  and  to  point  out  that  the  IFS  Is  Incomplete  or  at  variance  with 
the  DPSPR. 


CC_lK! 


CCMM^NDl-ID 


TYPEj  ,  INITIATE ^EKiGAGG.|VlEKiT._ MODE,  i  IemI 

TERMtKME  _EtOOAG€HEK]r_  MODE.  $ 


Figure  3-3  c2  input  Hierarchy 
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Iwpi)T_Tmtfwp ir.F  :  CC_TM. 

PASSES : 

MFSSAGF:  ^Onc_CHANJGF. 
message:  manpovfr 
mFSSagE:  TEP^TNATTOM. 

MESSAGE:  Mf)r)F_CHANIGF . 

MAPE  GY: 

data:  C,’>MMANri_in. 

MFSSAGF:  HAWOOVFP. 

MAPE  MY: 

mata:  C0MMAWr>_ID 
nATA:  HO_T!) 

HATA:  IMIT1 ALLSTATE 
HATA:  INTTIA1 _ COVARIANCE. 

MFSSAGF:  TERMINATION. 

MAPE  my: 

nATA:  cn^!4AMO_io 
pata:  ho_ t I) • 


Figure  3-4  RSL  Message  Entries 
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3.1.4  The  Interface  Data  Hierarchy 

At  this  point  we  have  partially  defined  the  elements  of  one  of  the 
two  major  data  hierarchy  types  associated  with  SREM.  This  is  th^  "inter¬ 
face  data  hierarchy"  depicted  in  Figure  3-5. 

A  SUBSYSTEM  is  CONNECTED  TO  either  an  INPUT  INTERFACE  or  an  0UTPUT_ 
INTERFACE  which  PASSES  blocks  of  data  called  MESSAGES.  A  MESSAGE  is  MADE 
BY  individual  items  of  DATA,  and/or  by  a  group  of  DATA  which  INCLUDES 
individual  DATA  items,  and/or  by  FILES.  In  turn,  a  FILE  CONTAINS  individual 
DATA  items.  The  RSL  concept  of  FILE  is  more  general  than  the  usual  software 
connotation.  It  is  simply  a  collection  of  instances  of  data,  each  instance 
having  the  same  content  of  data  items,  without  regard  to  the  details  of 
storage,  and  without  ordering  unless  specified. 

In  general,  a  data  item  must  have  a  different  DATA  name  in  each  hier¬ 
archy  in  which  it  appears,  even  though  the  different  names  refer  to  the  same 
information.  The  exception  is  that  DATA  o>'  FILEs  may  exist  in  more  than  one 
MESSAGE.  This  is  due  to  the  fact  that  only  one  MESSAGE  can  be  active  in  the 
system  at  any  time.  Therefore,  the  assembly  of  DATA  and  FILEs  into  a  MES¬ 
SAGE  is  unambiguous  regardless  of  the  number  of  MESSAGES  that  may  be  MADE 
BY  that  element.  For  example,  a  MESSAGE  PASSED  THROUGH  an  INPUTJNTERFACE 
only  exists  at  the  instant  of  passage  (i.e.,  the  enablement  of  the  interface 
network).  An  ALPHA  accesses  not  the  MESSAGE  but  the  DATA  it  contains;  there 
can  be  no  ambiguity  among  those  DATA  items  regardless  of  the  number  of  MES¬ 
SAGES  which  might  contain  them,  since  there  can  be  no  more  than  one  MESSAGE 
entering  the  system  for  a  given  enablement. 

SREM  is  heavily  oriented  toward  an  orderly  analysis  of  the  interface 
data  hierarchies,  in  a  "top  down"  direction,  as  the  first  step  in  defining 
DPS  requirements.  This  is  a  natural  direction,  as  the  interfaces  and  the 
messages  crossing  them  are  usually  the  most  clearly  defined  elements  of  the 
originating  specifications.  As  the  user  develops  the  data  definition  in 
progressively  greater  detail,  the  definition  of  specific  processing  steps, 
or  ALPHAS,  begins  to  emerge,  as  well  as  the  processing  flow  STRUCTURE  which 
links  the  ALPHAS. 

For  INPUT_INTERFACEs,  the  "top  down"  cons  i aeration  of  the  data  hie-- 
archy  follows  the  flow  of  processing.  For  OUTPUT_INTERFACEs,  the  "top  down" 
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SUBSYSTEM 


(CONNECTED  TO) 


_L 

INTERFACE 


( INPUTJNTERFACE 
\  OR 

(output  interface 


(PASSES) 


Figure  3-5  Interface  Data  Hierarchy 
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direction  Is  opposite  to  the  processing  flow.  However,  backward  tracing 
from  the  output  interface  is  a  valuable  tool  in  constructing  the  steps  neces¬ 
sary  to  form  an  output  MESSAGE. 

Initially,  the  internal  processing  required  of  the  DPS  may  be  i 1 1  - 
defined  and  ambiguous.  The  requirements  engineer  will  have  to  draw  heavily 
on  experience  to  synthesize  the  connections  between  input  and  output.  As 
an  aid  in  this  creative  process,  he  should  continually  ask,  "What  must  be 
done  to  the  data  I  have  in  order  to  provide  the  output  data  I  need?" 

3.1.5  Prrblems  of  Definition 
"Who  wrote  this  mess?" 

That  is  the  question  one  is  tempted  to  ask  when  he  encounters  sub- 

2 

paragraphs  3.2.5  and  3.2.6  of  the  C  /DPS  IFS.  Two  innocent  subparagraph 
titles  lead  to  a  number  of  confusing  questions,  which  are  typical  of  pre¬ 
liminary  specifications. 

The  titles  of  subparagraphs  3.2.1  through  3.2.4  correspond  to  clearly 

2 

defined  C  to  DPS  message  types,  and  the  content  of  the  text  addresses  those 
types.  The  contents  of  3.2.5,  titled  "Message  Acknowledgement",  and  3.2.6, 
titled  "Error  Handling",  are  TBS  (To  Be  Specified).  Do  these  titles  indi¬ 
cate  additional  input  message  types,  In  conflict  with  the  clear  definition 

In  paragraph  3.2?  If  so,  what  message  is  being  acknowledged  by  "Message 

2 

Acknowledgement"?  No  messages  from  DPS  to  C  have  been  defined,  and  no 

2 

requirement  for  a  DPS  output  Interface  to  the  C  system  is  Indicated.  In 
fact,  Figure  F-l  of  the  DPSPR  (Appendix  F)  clearly  Indicates  that  message 
traffic  Is  one-way,  from  C2  to  DPS. 

On  the  other  hand,  a  requirement  for  the  DPS  to  acknowledge  receipt 

2 

of  any  of  the  four  defined  C  to  DPS  message  types  by  transmitting  a  reply 
to  C2  may  be  intended.  If  so,  both  the  DPSPR  and  IFS  must  be  modified  to 
reflect  this,  without  ambiguity.  Similarly,  "Error  Handling"  might  refer 
to  either  a  message  type,  or  to  processing  in  response  to  erroneous  messages. 
Resolution  of  these  questions  is  Important  because  major  differences  in  DPS 
definition  result  from  the  alternatives. 

The  SREM  user  can  either  stop  work  until  the  problems  are  resolved, 
or  can  proceed  tentatively  with  the  assumptions  which  make  the  most  sense. 
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If  he  chooses  to  proceed,  he  should  take  time  to  note  the  problem  in  the 
ASSM  and  identify  what  elements  are  affected  by  his  assumptions.  Figure  3-6 
shows  one  way  of  doing  this,  for  the  message  acknowledgement  problem,  using 
the  RSL  management  segment.  These  entries  announce  the  problem  and  indicate 
changes  needed  later  if  the  assumptions  are  wrong. 

The  user  may  object  on  the  grounds  that  making  these  entries  and 
recording  these  questions  is  tedious  and  ta^es  up  his  time.  True.  How¬ 
ever,  more  of  his  time  would  be  taken  up  by  other  people  asking  the  same 
questions  over  and  over  again.  Worse  yet,  others  may  make  different  assump¬ 
tions  or  fail  to  detect  the  ambiguities.  The  result  is  more  time  spent 
later  on  rework.  With  the  information  recorded  in  the  ASSM,  the  answers 
are  available  to  everyone  -  even  to  those  who  haven't  yet  thought  of  the 
questions. 

It  is  not  within  the  scope  of  this  manual  to  explore  all  the  aspects 
of  traceability  and  uses  of  the  RSL  management  segment.  With  this  brief 
illustration  we  will  drop  the  subject.  For  further  development  of  the  TLS 
example,  we  will  assume  that  the  problems  are  resolved  as  follows: 

•  A  message  called  ACKNOWLEDGEMENT  consisting  of  one  data  element, 
COMMANDED,  is  required. 

2 

•  This  message  is  passed  from  DPS  to  C  via  a  new  output  inter¬ 
face,  CCJOUT. 

•  "Error  Handling"  refers  to  error  processing  required  of  the 
DPS  when  a  message  from  O-  is  not  identified  as  one  of  the 
four  defined  types. 

3.1.6  R_NET  Definition 

A  Requirements  Net,  or  R_NET  is  used  to  describe  the  required  flow  of 
processing  in  response  to  a  single  stimulus  which  ENABLES  the  net.  This 
stimulus  may  be  either  the  passage  of  a  MESSAGE  through  an  INPUT_INTERFACE, 
or  an  EVENT  defined  by  arrival  at  a  node  on  the  subject  R_NET  or  on  some 
other  R  NET  associated  with  the  DPS. 


Each  INPUT_INTERFACE  must  enable  an  R_NET.  Otherwise,  DATA  in  a 
MESSAGE  passing  the  interface  could  not  be  processed  by  the  DPS.  Hence, 
there  must  be  at  least  one  R_NET  for  each  INPUT_INTERFACE,  since  only  the 
processing  on  an  R_NET  can  distinguish  between  the  arriving  messages.  Thus, 
the  first  logical  step  in  defining  the  R_NETS  of  the  DPS  is  to  define  one  for 
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DECISION:  hF^NTnS.OF  _MESSAGP_rtCKNOrfLFnGFMFNT . 

PR08LFMJ  •  T  MPL  TCAT  ?ON  OF  CC  TO  OPS  IFS  PARAGRAPH  ?l-2-S 

TS  NOT  CLFAR.  REVISION  OK  THIS  PARAGRAPH  AND/OR 
OPSPR  FIGURE  1-1  IS  MFFDFD. ", 

ALTF Rmativfs: 


"1.  INTFPPRET  MFSSAGE  ^CKNO*LFPG£m£nT  AS  A  MESSAGE  TYPE 
FROM  CC  TO  OPS. 

?.  INTERPRET  AS  A  MESSAGE  FROM  DPS  TO'  CC  IN  RESPONSE 
TO  EACH  CC  TO  OPS  MESSAGE.'  THIS  NEEDS'  A  DPS 
'  OUTPUT  INTERFACE  TO  CC. ",  .  *  * 

CHOICE:  '  '  '  ‘  ’  ’ 

■PROCEED  WITH  AtTFWNATIVE  ?  PENOING  FORMAL  RESOLUTION." 


) 


V 


Flfurt  3-6  RSL  Decision  Entry 
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each  I NPUT_I NTERFACE .  In  the  TLS  example,  three  such  interfaces  have  been 
previously  defined,  so  we  need  to  develop  three  corresponding  R_NETs. 

R_NETS  may  be  entered  into  the  ASSM  manually  from  the  Anagraph  termi¬ 
nal,  or  via  a  card  deck  of  RSL  statements.  No  matter  which  method  is  used, 
the  net  should  be  diagrammed  on  paper  first  to  develop  the  concept  fully  and 
minimize  revisions. 

As  a  first  example,  let  us  consider  the  R_NE7  enabled  by  interface 

C C I N .  Following  the  initial  node  on  the  net,  one  draws  the  INPUT  INTERFACE 

itself.  It  is  reasonable  then,  but  not  mandatory,  to  provide  an  ALPHA  for 
common  processing  of  all  MESSAGES  through  that  interface,  for  such  purposes 
as  validating  data  common  to  all  MESSAGES.  Thus,  we  have  this  typical 
starting  structure. 


VALIDATE 

HEADER 


It  was  noted  in  defining  the  MESSAGES  that  they  are  distinguished  by 
the  differences  in  their  data  contents.  Since  the  input  to  an  ALPHA  is  fixed, 
there  must  be  a  unique  ALPHA  for  each  MESSAGE.  There  also  may  be  several 
message  types  for  each  MESSAGE,  and  it  is  reasonable  to  expect  different  pro¬ 
cessing,  hence  different  ALPHAS,  for  each  type.  While  not  always  true,  this 
is  usually  a  profitable  assumption  at  this  stage  of  R_NET  development.  Fur¬ 
ther,  an  additional  ALPHA  is  usually  needed  for  error  processing  of  messages 
not  recognized  as  one  of  the  valid  types.  Therefore,  it  is  possible  to  draw 
the  following  skeleton  associated  with  an  input  interface  with  the  information 
gained  from  our  preceding  analyses  of  the  specifications.  (Refer  to  Appendix 
A  for  symbols  and  allowable  structures.) 
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The  OR  node  with  multiple  branches,  as  shown,  is  described  in  RSL  with 
the  aid  of  the  CONSIDER  phrase.  The  object  of  consideration  is  a  data  ele¬ 
ment  with  an  enumerated  set  of  values,  in  this  case  the  data  element  COMMAND 
ID.  If  the  value  of  COMMANDED  in  a  particular  message  does  not  match  the 
value  of  any  branch,  the  OTHERWISE  branch  is  invoked. 

The  ALPHAS  defined  above  reflect  all  processing  required  for  a  given 
message  type.  The  names  chosen  reflect  a  gross  conception  of  the  nature 
of  the  processing.  They  are  subject  to  change.  As  analysis  proceeds  the 
definition  of  the  R_NET  will  be  refined.  The  first  tentative  ALPHAS  may 
expand,  and  the  branching  structure  will  be  modified  for  all  but  the  sim¬ 
plest  systems.  Hence,  the  SREM  user  should  not  rush  to  enter  an  R_NET  into 
the  ASSM  at  the  first  opportunity.  He  should  wait  until  the  definition  of 
the  net  has  stabilized  and  possible  relations  with  other  R_NETS  are 
comprehended. 

Where  the  previous  effort  was  purely  mechanical,  it  is  now  necessary 
to  apply  some  creativity  to  complete  the  interface  network.  There  are  two 
fundamental  approaches  to  that  completion  from  the  available  documentation: 
thread  tracing  and  sentential  analysis.  Both  should  be  used  so  that  com¬ 
pleteness  of  statement  is  assured. 
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The  first  operation  is  thread  tracing.  By  reading  the  source  speci¬ 
fications,  the  processing  steps  required  may  be  traced  from  an  input  port 
to  their  logical  termination.  When  all  paths  have  been  traced,  not  only 
for  the  input  networks  but  also  for  those  developed  in  the  following  para¬ 
graphs,  the  set  of  processing  steps  (ALPHAs)  required  should  be  complete. 
Sentential  analysis  provides  a  cross-check  by  separating  each  specification 
sentence  into  its  nouns  (which  correspond  to  system  data)  and  its  verbs 
(which  correspond  to  ALPHAs).  The  two  sets  of  ALPHAs  should  be  identical; 
if  not,  they  are  made  to  be  through  refinement  of  the  diagrams. 

The  result  of  specification  analysis  is  completion  of  the  paths  from 
each  INPUT_INTERFACE.  For  example,  there  is  a  requirement  in  the  TL5  that 
each  MESSAGE  received  from  the  CC  be  acknowledged.  Therefore  the  AND  node 
is  added,  an  ALPHA  is  provided  to  FORM  the  MESSAGE:  ACKNOWLEDGEMENT,  and 
the  appropriate  OUTPUTINTERFACE:  CC  OUT  is  indicated.  Continuing  the 
process,  we  arrive  at  the  following  diagram.  It  is  a  complete  R_NET  for 
RESPONSETOCC  requirements  for  TLS  except  that  it  does  not  yet  reflect 
inter-network  connectivity.  Note  that  each  branch  ends  at  either  an  OUTPUT 
INTERFACE,  or  at  a  TERMINATE  symbol. 
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In  tracing  input  networks,  many  of  the  MESSAGES  to  be  output  by  the 
software  will  have  been  isolated.  However,  not  all  messages  for  any  0UTPUT_ 
INTERFACES,  nor  indeed  any  MESSAGE  for  some  of  them,  may  be  defined.  Thus, 
there  is  an  inverse  operation  for  output  networks  which  trace  back  from  an 
OUTPUT_INTERFACE  through  individual  ALPHAS  for  each  possible  MESSAGE  to  the 
earliest  operation  required  of  it  in  the  specifications. 

This  procedure  is  not  necessary  for  the  network  above.  All  MESSAGES 
passed  by  CC_IN  require  an  ACKNOWLEDGEMENT  message  response  to  be  passed  by 
CCjOUT.  All  HANDOVER  messages  clearly  require  a  TRACK_INITIATION  message 
to  be  passed  by  DATARECORD.  The  above  network  completely  describes  the 
only  conditions  where  these  responses  are  generated  within  the  DPS.  A 
TRACK_TERMI NATION  message  is  passed  by  DATA_RECORD  in  response  to  an  input 

TERMINATION  message  passed  by  CC _ I N .  However,  this  case  represents  only 

one  condition  where  a  TRACKJTERMINATION  message  is  generated  by  the  DPS. 

The  remaining  conditions  will  occur  on  other  R_NETs.  But,  all  of  these 
responses  have  one  thing  in  common.  Each  is  a  single  MESSAGE  passed  through 
a  specific  OUTPUT_INTERFACE  in  response  to  a  given  MESSAGE  or  class  of 
MESSAGES  passed  by  a  single  specific  INPUT_INTERFACE.  These  are  examples 
of  "synchronous  processing":  the  input  is  joined  to  the  output  by  a  direct 
path  of  processing  steps,  and  none  of  the  data  used  are  modified  by  process¬ 
ing  performed  on  any  other  path. 

In  the  context  of  R_NETs ,  logical  connectivity  is  maintained,  not  only 
by  a  continuous  path  through  one  R_NET,  but  perhaps  through  additional  R_NETS, 
by  means  of  EVENTS.  An  EVENT  is  an  alternate  means  for  enabling  an  R_NET. 

A  single  logical  path  is  formed  by  the  path  leading  to  the  event  on  the 
enabling  R_NET  and  continuing  on  a  path  on  the  enabled  R_NET.  Such  paths 
represent  "synchronous  processing"  only  if  none  of  the  data  used  are  modi¬ 
fied  by  an  independent  path, 

"Asynchronous  processing"  is  a  more  complex  concept  to  grasp.  This 
type  of  processing  is  implicit  when  two  R_NETs  are  related  by  data,  but 
without  the  "logical  connectivity"  represented  by  flowing  tokens.  An  exam¬ 
ple  Involving  three  simple  R_NETs  will  serve  to  illustrate  the  basic  forms 
of  "asynchronous  processing."  The  example  is  defined  In  Figure  3-7. 

Whenever  a  subsystem  SSI  passes  an  XIN  message  through  the  DPS  Inter¬ 
face  SS1_IN,  the  R_NET  named  XJ/ALUE  is  enabled.  This  R_NET  accepts  the 
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Figure  3-7  Three  Asynchronous  R__NETs 


data  NEW_X  in  the  message  and,  if  NEW_X  satisfies  certain  conditions,  up¬ 
dates  the  value  of  a  global  variable,  X,  to  the  value  of  NEW_X.  Whenever 
a  second  subsystem,  SS2,  passes  a  YIN  message  through  the  interface  S$2_IN, 
the  R  NET  named  Z_VALUE  is  enabled.  This  R_.NET  accepts  the  data  Y  in  the 
message  and  adds  it  to  the  current  value  of  X  defined  in  the  data  bast  to 
form  Z  (defined  as  a  global  variable  for  this  example).  The  value  of  Z  is 
contained  in  the  ZOUT  message  sent  to  SS?  via  SS20UT,  but  is  also  retained 

in  the  DPS  because  Z  is  defined  as  global  data.  Further,  a  third  R_NET 

2 

named  ZZ_VALUE  periodically  enahles  itself,  to  compute  Z  ,  by  means  of  an 
event  on  its  own  structure  and  an  associated  time  delay.  The  value  of  Z 
which  is  used  is,  of  course,  that  which  is  current  in  the  data  base.  There 
is  no  specific  order  of  enablement  required  of  the  R_NETs. 

When  the  reader  experiments  with  this  system  a  little,  he  will 
quickly  realize  that  the  values  of  Z  and  Z  depend  not  only  on  the  inputs  X 
and  Y  (or  their  previous  values),  but  also  on  the  sequence  of  enablement  of 
the  R_NETs.  Thus,  within  a  given  time  interval,  there  is  not  a  one-to-one 
correspondence  between  the  latest  values  of  X  and  Y  and  the  latest  values  of 
2 

Z  and  Z  .  For  that  matter,  no  such  correspondence  exists  between  Z  and 

z2. 

A  simple  example  of  "asynchronous  processing"  in  the  TLS  example 
might  be  the  use  of  radar  clock  time.  The  sole  function  of  the  R_NET 
called  RADAR_TIMING  is  to  accept  timing  inputs  from  the  radar  and  update 
the  global  variable  RADARjCLOCK.  If  another  R_NET  needed  radar  time,  it 
would  use  the  value  of  RADARjCLOCK.  This  value  does  not  reflect  the  cur¬ 
rent  time,  but  rather  the  time  at  which  the  radar  formed  the  message  which 
was  last  accepted  by  the  R_NET  called  RADAR_TIMING. 

The  major,  and  most  complicated,  example  of  "asynchronous  processing" 
In  the  TLS  is  the  relationship  between  radar  returns  and  the  next  set  of 
radar  commands.  Synchronous  tracking  would  require  that  data  from  the  last 
radar  return  from  an  object  be  used  to  produce  the  next  succeeding  radar 
order  related  to  that  object.  Asynchronous  tracking  allows  use  of  the  last 
data  available  In  the  DPS,  even  though  more  current  data  may  be  coming  soon 
from  the  radar.  Asynchronous  tracking  allows  less  stringent  DP  response 
times,  better  time-line  usage,  and  permits  gradually  degraded  response  with 
Increased  system  load.  Synchronous  tracking,  on  the  other  hand,  places 
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stringent  constraints  on  the  DP  which  lead  to  saturation  and  loss  of  track 
under  relatively  light  load. 


The  definition  of  an  asynchronous  processing  concept  is  subtle  and 
difficult,  and  is  fraught  with  traps  for  the  unwary.  No  cookbook  solutions 
can  be  offered  for  this  creative  process.  First,  the  R_NETs  must  be  traced 
both  forward  from  the  input  interfaces  and  backward  from  the  output  inter¬ 
faces.  The  data  and  logical  connectivity  to  fill  the  gaps  between  must  then 
be  added  through  an  active  and  creative  engineering  thought  process.  Note 
that  SREM  does  provide  a  framework  of  organization  which  fosters  consistency, 
and  ultimately  leads  to  a  simulation  which  can  detect  errors  of  concept. 

While  the  SREM  user  is  filling  in  the  gaps  in  the  DPS  definition,  he 
must  constantly  remember  that  he  is  not  designing  software.  Rather,  he  is 
defining  the  requirements  which  that  software  must  satisfy.  When  he  has 
invented  a  construct  which  appears  to  meet  the  needs,  and  which  survives 
simulation,  he  should  view  it  only  as  an  example  which  demonstrates  that 
a  DPS  solution  to  system  requirements  is  feasible.  It  is  probably  not  the 
only  valid  solution,  nor  should  it  be  specified  as  such.  The  SREM  user 
should  constantly  reexamine  his  constructs  to  ensure  that  they  embody  the 
requirements  in  the  most  general  statements  he  can  formulate.  If  he  pur¬ 
sues  details  beyond  the  point  needed  to  clearly  state  the  required  proper¬ 
ties  of  the  DPS,  he  is  overly  constraining  the  design. 

When  the  user  reaches  an  impasse  in  further  defining  the  R_NETs,  he 
will  find  it  profitable  to  define  the  "entities"  with  which  the  DPS  is  con¬ 
cerned,  and  the  data  hierarchies  associated  with  them.  These  are  discussed 
in  3.1.7  and  3.1.8.  These  steps  will  sharpen  his  concepts  of  the  data  flow 
within  the  DPS,  and  should  suggest  ways  of  bridging  the  gaps  in  the  processing. 
Then  the  user  can  return  to  complete  the  R_NETs,  and  possibly  add  intervening 
RJiETs. 

3.1.7  Entity  Definition 

One  of  the  most  powerful  concepts  used  in  SREM  is  that  of  an  "entity". 
This  concept  allows  the  user  to  express  more  clearly  the  role  of  the  DPS 
requirements  in  the  same  operation,  and  the  RSL  facilities  provided  tend  to 
enforce  that  perspective.  An  "entity"  is  simply  a  thing,  or  category  of 


things,  in  the  external  world  about  which  the  DPS  must  collect,  process, 
and  maintain  data.  Entities  are  closely  tied  to  the  reasons  for  the  exis¬ 
tence  of  the  system  and  its  DPS.  They  are  usually  implicit  in  the  wording 
of  the  originating  specifications,  although  the  new  SREM  user  must  train 
himself  to  recognize  those  which  are  of  significance. 

For  instance,  the  basic  purpose  of  the  TLS  is  to  gather  data  on  the 
position  and  velocity  of  designated  objects  within  its  detection  range  in 
order  to  predict  the  position  and  velocity  of  those  objects  at  some  future 
time.  This  suggests  that  "objects"  might  be  an  entity.  However,  "desig¬ 
nated  objects"  would  be  a  better  candidate,  because  the  TLS  is  not  expected 
to  detect  any  objects  other  than  those  the  C  System  orders  it  to  track. 

If  we  were  considering  the  TLS  as  a  whole,  this  might  be  a  reason¬ 

able  choice.  But,  we  are  focusing  on  the  DPS.  The  DPS  is  not  "aware"  of 
objects  because  it  does  not  perceive  them  directly.  The  radar  performs 
the  sensor  functions.  Thus,  the  DPS  is  only  aware  of  what  the  radar  per¬ 
ceives  as  objects  and  reports  to  the  DPS.  The  nomenclature  of  the  DPSPR 

calls  these  "images".  Further  reading  of  the  DPSPR  shows  that  much  of  the 
DPS  processing  is  concerned  with  the  proper  classification  of  these  images, 
and  eventual  elimination  of  those  which  do  not  correspond  to  real  objects 
(ghosts),  or  which  are  redundant  images  of  the  same  object.  During  the 
time  that  an  image  is  considered  an  "image  in  track",  a  certain  instance 
of  data  items  must  be  maintained  in  the  DPS  and  be  associated  with  the 
proper  image.  When  the  DPS  decides  that  the  image  is  probably  redundant 
or  a  ghost,  or  should  drop  track  on  that  image  for  other  reasons,  the  DPS 
must  maintain,  for  a  time,  a  different  set  of  data  about  that  image. 

Thus,  we  have  a  notion  of  a  general  category  of  things  called  "images" 
which  are  of  importance  to  the  DPS.  In  SREM,  such  a  category  is  called  an 
ENTITY_CLASS.  Hence,  for  TLS  we  will  define  an  ENTITYjCLASS  named  IMAGE. 

We  are  aware  of  two  types  of  IMAGE,  distinguished  by  the  different  data 
associated  with  each  type.  Therefore,  we  will  designate  two  ENTITYJTYPEs, 
called  IMAGE_IN_TRACK,  and  DROPPEDJMAGE.  Each  IMAGE  of  which  the  DPS  is 
aware  has  an  instance  of  data  uniquely  associated  with  it.  This  instance 
may  be  composed  of  DATA  Items  and  FILEs.  The  composition  of  the  instance 
is  a  function  of  ENTITY_TYPE  and,  by  definition,  should  be  different  in  some 
manner  from  at  least  one  other  type  in  the  class.  However,  data  common  to 
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all  types  may  be  associated  with  the  ENTITY_CLASS  itself.  Two  types  may 
have  identical  data  associated  with  them.  These  usually  imply  a  tran¬ 
sition  from  a  common  earlier  state  (e.g.,  an  ENTITY_TYPE  I  is  set  to 

either  ENTITY _ ^TYPE  J  or  ENTITY_TYPF  K  depending  on  some  decision  in  the 

DPS). 

A  second  ENTITYjCLASS  is  defined  in  TLS  for  each  radar  PULSE.  The 
pulse  is  an  external  phenomenon  (an  electromagnetic  signal)  about  which  the 
data  processor  is  found  to  need  data,  and  which  exists  in  multiple  copies. 
Therefore,  it  satisfies  the  criteria  for  consideration  as  an  ENTITYjCLASS. 

The  fact  that  data  must  be  'remembered'  about  each  pulse  while  it  is  in 
transit,  and  the  required  data  themselves,  derive  from  the  IFS  through  the 
process  of  defining  the  functional  requirement.  Thus,  when  considering  the 
determination  of  range  to  the  target,  it  is  necessary  to  know  both  the  start 
time  of  the  range  gate  relative  to  the  start  of  transmission  and  the  time 
within  the  gate  that  the  signal  was  detected.  The  IFS  asserts  that  the 
radar  return  contains  the  time  within  the  gate;  the  start  time  of  the  gate 
must  therefore  be  'remembered'  by  the  data  processor  from  the  command  which 
gave  rise  to  the  return.  Thus,  the  data  required  on  a  pulse  in  transit  have 
to  do  with  the  transmission  parameters  relevant  to  different  pulse  waveforms. 
Consideration  of  data  and  logical  usage  differences  leads  to  the  definition 
of  four  ENTITYTYPES  named  T1-T2,  T3,  RETURNED_PULSE,  and  LOST_PULSE  within 
the  ENTITY_CLASS  PULSE. 

3.1.8  The  Entity  Data  Hierarchy 

The  second  major  data  hierarchy  associated  with  SREM  is  the  "entity 
data  hierarchy"  depicted  in  Figure  3-8.  The  means  for  manipulating  data 
contained  in  an  entity  herarchy  differ  from  those  used  with  the  interface 
hierarchies  of  3.1.4. 

An  ENTITY_CLASS  is  COMPOSED  OF  one  or  more  ENTITY_TYPES.  If  there 
are  data  elements  common  to  all  ENTITY_TYPF.S,  then  the  ENTITY_CLASS  ASSOCIATES 
these  DATA  items  and  FILEs.  For  data  elements  specific  to  an  entity  type, 
the  ENTI TY_TYPE  ASSOCIATES  the  applicable  data  elements.  Once  again,  the 
DATA  item  is  the  lowest  element  in  the  hierarchy.  Each  FILE  CONTAINS  items 
of  DATA. 
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The  chief  characteristic  of  the  entity  data  hierarchy  is  the  unique 
method  of  manipulating  data  which  is  implemented  in  RSL.  There  is  no  way, 
in  RSL,  for  a  user  to  specify  that  a  FILE  be  created  or  destroyed  by  an 
ALPHA.  FILEs  may  only  be  modified  by  ALPHAS  (although  instances  in  files 
are  created  or  destroyed  in  the  BETA  models).  RSL  provides  a  mechanism  to 
require  that  an  ALPHA  is  to  CREATE  or  DESTROY  the  knowledge  that  an  instance 
of  an  ENTITY  CLASS  exists  in  the  environment.  When  an  ALPHA  creates  a  new 
instance  of  an  ENTITY_CLASS,  a  new  instance  of  all  the  common  DATA  and  FILEs 
ASSOCIATED  WITH  that  class  is  initialized.  The  ALPHA  may  then  assign  proper 
values  to  those  data  elements.  These  data  elements  are  retained  throughout 
the  life  of  the  instance. 

The  ALPHA  can  also  SET  the  ENTITY _ ^TYPE .  When  this  is  done,  an  instance 

of  all  the  specific  DATA  and  FILEs  ASSOCIATED  WITH  the  ENTITYJYPE  is 
initialized  and  can  be  assigned  proper  values.  When  the  instance  of  ENTITY_ 
CLASS  is  SET  to  a  new  ENTITY_TYPE,  the  specific  data  elements  unique  to  the 
old  type  are  destroyed  and  a  new  instance  of  data  elements  specific  to  the 
new  type  is  initialized. 

As  the  data  processing  system  gathers  information  about  an  entity,  it 
may  first  identify  the  entity  as  being  of  one  ENTITYTYPE,  and  then  another. 
Instances  of  a  class  of  entities  thus  evolve  from  one  type  to  another,  but 
instances  of  one  class  (e . g . ,  IMAGEs)  can  never  evolve  into  another  class 
(e.g.,  PULSEs).  Each  ENTITY  TYPE  therefore  COMPOSES  just  one  ENTITY_CLASS. 

An  instance  belongs  to  one  ENTITY_CLASS  after  an  ALPHA  CREATES  it,  and  it 
belongs  to  the  last  ENTITY_TYPE  to  which  an  ALPHA  SETS  it.  Eventually,  an 
ALPHA  may  DESTROY  (knowledge  of)  the  instance,  and  all  data  associated  with 
the  instance  vanish.  Although  the  RSL  statements  for  CREATE  and  DESTROY 
refer  to  the  name  of  the  ENTITY_CLASS,  the  operation  is  applicable  only 
to  a  single  instance. 

This  concentration  of  the  requirements  for  creation  and  destruction  of 
knowledge  about  external  entities,  rather  than  the  mechanics  of  data  struc¬ 
tures,  allows  the  user  to  focus  on  the  requirements  for  the  DPS  as  a  part 
of  the  system  in  which  it  is  embedded.  Otherwise,  the  user  would  tend  to 
stray  into  process  design  issues,  such  as  when  to  set  up  FILEs. 


r 

As  was  done  with  MESSAGES  in  3.1.3,  it  is  useful  to  diagram  the  entity 
data  hierarchies  before  coding  them  in  RSL.  Figure  3-9  shows  diagrams 
of  the  TLS  hierarchies  associated  with  the  two  ENTITY_CLASSes ,  PULSE  and 
IMAGE.  When  the  user  decides  that  the  definitions  are  stable  and  ready  to 
enter  in  the  ASSM,  the  entries  can  be  coded  in  RSL  as  shown  in  Figure  3-10 
for  IMAGE. 

3.1.9  Independent  FILES 

When  the  user  is  defining  the  processing  requirements,  he  may  become 
aware  of  the  need  for  data  sets  which  fit  in  neither  a  transient  Interface 
data  hierarchy  nor  a  permanent  entity  data  hierarchy.  These  should  have 
the  properties  of  1)  multiple  Instances  of  a  data  Item  or  data  group,  and 
either  2)  a  need  to  be  retained  as  GLOBAL  data,  or  3)  a  need  to  be  ordered 
In  some  particular  way,  or  4)  a  need  to  be  temporarily  maintained  as  a  class 
of  data  meeting  some  selection  criteria.  These  needs  can  be  satisfied  by 
defining  an  Independent  FILE.  This  FILE  exists  In  the  DPS  at  all  times, 
even  though  it  may  be  empty.  Although  instances  in  the  file  can  be  created 
and  destroyed  within  BETA  and  GAMMA  executable  descriptions  of  ALPHAS,  the 
FILE  itself  cannot  be  created  or  destroyed.  It  can  only  be  modified.  FILES 
can  be  INPUT  TO  ALPHAS  or  OUTPUT  FROM  ALPHAS  or  both. 

The  distinction  between  the  concepts  of  ENTITYjCLASS  and  independent 
FILE  often  may  appear  fuzzy.  The  key  distinction  is  that  a  FILE  is  a  set  of 
data,  an  ENTITY_CLASS  Is  the  subject  of  data. 

In  the  TLS,  there  exists  a  file  of  constants  called  WAVEFORM_TABLE. 
This  FILE  Is  part  of  the  site-adaptation  data  for  the  system,  and  Is  Inde¬ 
pendent  of  real-time  Input.  Two  other  TLS  examples  of  Independent  FILEs 
are  those  called  COMMAND  and  CANDIDATE.  These  files  are  dynamic  (l.e. 
change  In  response  to  real-time  data).  Both  of  these  files  are  used  to 
select  Instances  from  ENTITY_TYPE  IMAGE_IN_TRACK  and  to  order  the  extracted 
data  to  determine  new  Instances  of  ENTITY_CLASS  PULSE.  Thus,  these  files 
are  part  of  the  data  bridge  between  the  two  ENTITY  CLASSes  In  TLS. 
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Figure  3-9  Entity  Hierarchy 
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Figure  3-10  RSL  Entity  Entry 


3.1.10  Summary  of  Phase  1 

This  section  has  outlined  a  general  procedure  for  defining  the  ele¬ 
ments  needed  to  specify  the  requirements  for  the  DPS.  At  this  point  many 
of  the  definitions  are  gross  and  tentative.  The  constructs  may  have  been 
entered  into  the  ASSM  as  they  were  defined,  or  they  may  just  exist  on  paper. 
This  choice  is  up  to  the  user,  and  depends  upon  the  size  and  nature  of  the 
DPS  problem,  and  the  number  of  people  involved. 

The  following  "top  down"  sequence  of  steps  has  proved  to  be  the  most 
effective: 

1)  Define  the  subsystems  relevant  to  the  DPS. 

2)  Define  the  interfaces  connecting  the  DPS  to  the  sybsystems. 

3)  Establish  the  messages  passing  through  the  interfaces,  and 
define  their  data  contents. 

4)  Develop  the  R  NETs  originating  at  input  interfaces. 

5)  Construct  processing  steps,  tracing  backward  from  the  output 
interfaces  when  necessary. 

6)  Define  the  entities  of  concern  to  the  DPS,  and  the  associated 
data  hierarchies. 

7)  Define  independent  files  as  necessary. 

8)  Refine  the  R_NETs  and  create  new  ones,  as  needed,  to  link 
the  input  and  output  interfaces. 

Some  variation  on  this  sequence  may  be  appropriate  to  certain  problems,  but 
the  basic  principle  is  to  move  from  known  interfaces  to  internal  processing 
steps,  using  the  data  definitions  as  a  vehicle. 

The  ALPHAS  defined  at  this  point  will  be  primitive,  and  will  reflect 
high  level  concepts  of  the  nature  of  the  processing.  In  Phase  3  (Section  3.3) 
they  will  be  modified,  and  expanded  into  subnets,  as  necessary.  But  first. 
Phase  2  (Section  3.2)  is  needed  to  consolidate  the  information  developed  and 
to  ensure  that  It  forms  a  consistent  basis  for  detailed  development. 

3.2  PHASE  2  -  EVALUATION  OF  THE  KERNEL 

Before  completing  the  definition  of  the  functional  requirements  struc¬ 
ture,  it  is  prudent  to  enter  the  information  derived  in  Phase  1  (3.1)  into 
the  ASSM  and  check  the  results,  both  manually  and  with  the  aid  of  Require¬ 
ments  Analysis  and  Data  Extraction  (RADX)  procedures.  Therefore,  all  infor- 
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convenience  should  be  loaded  Into  the  ASSM  at  this  time.  This  nucleus  of 
information,  called  the  "kernel",  constitutes  the  Irreducible  minimum  needed 
to  document  the  major  elements  of  the  functional  requirements  definition. 

In  this  section  we  will  suggest  particular  points  for  the  user  to  check, 
and  will  refer  him  to  TLS  examples  in  Appendix  C. 

3.2.1  Data  Naming  Conventions 

RSL  has  been  designed  to  force  the  user  into  precision  of  thought, 
with  respect  to  data  definition,  at  an  early  stage.  A  single  item  of  infor¬ 
mation  may  require  several  different  DATA  names  In  the  course  of  Its  exis¬ 
tence  in  the  system.  These  are  applied  as  the  usage  of  the  information  and 
its  properties  of  transience  or  permanence  dictate.  Naming  Is  a  tedious 
process,  and  may  lead  to  a  variety  of  awkward  names,  but  It  Is  mandatory 
in  the  development  of  a  coherent,  unambiguous  DPS  model.  While  the  RSL 
translator  will  detect  most  common  ambiguities  or  conflicts,  the  user  should 
continually  refine  his  understanding  of  the  data  flows  within  the  DPS  In 
order  to  catch  more  subtle  errors. 

The  entity  data  are  the  first  to  display  the  constraints  Imposed  by 
RSL  naming  conventions.  In  general,  it  is  necessary  that  a  data  element 
exist  in  only  a  single  hierarchy;  the  sole  exception  Is  that  it  may  exist 
In  multiple  MESSAGES.  Thus,  we  find  that  the  identifier  of  an  image  being 
tracked  Is  both  the  TARGETJD  ASSOCIATED  WITH  PULSE  and  the  IMAGEJD  ASSO¬ 
CIATED  WITH  IMAGE.  The  two  values  are  the  same  when  the  TARGET_ID  Is 
assigned,  but  note  that  the  destruction  of  an  instance  in  one  ENTITYjCLASS 
is  unrelated  to  the  existence  of  an  Instance  of  any  other.  The  meaning  of 
a  single  identifier,  if  the  IMAGE  Instance  were  destroyed  while  the  PULSE 
was  still  active,  would  be  Indeterminate.  It  Is  only  to  resolve  such  Inde¬ 
terminacy  that  the  naming  rules  are  Imposed;  here,  the  "same"  Information 
Is  given  different  names  for  the  two  occurrences  In  different  hierarchies,. 

The  Identifier  used  for  an  IMAGE  is  given  to  the  RESP0NSE_T0_CC  R_NET 
as  a  H0_ID  (handover  Identifier).  The  same  name  Is  applied  to  a  drop-track 
command  when  a  TERMINATION  message  Is  sent,  and  also  any  of  three  MESSAGES 
through  the  DATA_RECORD  Interface,  whenever  Information  about  that  image  Is 
updated.  However,  when  the  information  Is  to  be  held  In  global  storage 
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(such  as  for  an  entity),  a  difference  name  must  be  applied  (IMAGE_ID  for  the 
IMAGE  class,  TARGETJD  for  PULSE).  The  requirement  for  renaming  to  avoid 
ambiguity  is  needed  in  order  to  construct  an  executable  description  (Section 
3.4). 


3.2.2  Structural  Data  Definitions 

R  NETS  can  be  entered  into  the  ASSM  in  two  ways.  Using  REVS  in  the 
ONLINE  mode,  the  nets  can  be  entered  interactively  via  the  Anagraph  terminal 
at  the  ARC  facility.  Using  REVS  in  the  OFFLINE  mode,  the  nets  can  be  speci¬ 
fied  by  an  input  deck  of  RSL  statements.  If  the  offline  mode  is  used,  cer¬ 
tain  DATA  which  are  integral  to  the  R_NET  structure  must  be  defined  with 
appropriate  statements  before  the  set  of  statements  which  define  the  STRUC¬ 
TURE  of  the  R  NET  can  be  integrated.  Prior  data  definition  is  not  necessary 
if  the  Anagraph  terminal  is  used,  but  should  be  accomplished  within  Phase  2 
for  completeness  of  the  kernel. 

Structural  DATA  elements  include  those  which  are  referenced  in  FOR  EACH 
statements,  CONSIDER  statements  associated  with  an  OR  node,  and  conditional 
expressions  associated  with  an  OR  node.  The  latter  two  types  are  called 
"selection  variables."  Other  DATA  which  should  be  defined  at  this  point  are 
those  which  DELAY  the  occurrence  of  an  EVENT  or  ORDER  a  FILE. 

The  FOR  EACH  statement  may  be  absolute  or  conditional.  The  object 
upon  which  the  statement  operates  can  be  an  ENTITY_CLASS,  ENTITYJTYPE,  or 
FILE.  While  the  FILE  is  usually  associated  with  one  of  the  interface  or 
entity  hierarchies,  assumed  to  be  defined  previously,  some  FILFs  may  exist 
independently  from  any  hierarchy,  as  discussed  in  3.1.9.  The  user  should 
verify  that  all  elements  used  in  FOR  EACH  statements  are  declared  in  the 
ASSM  prior  to  the  R_NET  which  uses  them.  Elements  used  in  the  condition 
part  of  a  conditional  FOR  EACH  must  be  defined  as  discussed  below  for 
selection  variables. 

Selection  variables  require  added  definition  at  this  point  because 
of  the  merhanics  of  the  RSL  translation  process.  In  addition  to  declara¬ 
tion  of  the  DATA  name,  its  TYPE  must  be  identified.  Further,  if  the  TYPE 
is  ENUMERATION,  the  RANGE  of  values  must  be  defined  before  the  R_NET  STRUC¬ 
TURE  can  be  translated. 
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While  not  mandatory,  it  is  recommended  that  the  LOCALITY  and  USE 
attributes  for  selection  variables  also  be  defined  at  this  point,  and  be 
verified  manually.  This  Is  because  REVS  consistency  analysis  does  not 
Include  DATA  referenced  In  conditional  expressions.  Thus,  the  software 
cannot  detect  definition  errors  until  execution  of  a  BETA  or  GAMMA  simu¬ 
lation.  Figure  3-11  shows  RSL  Inputs  which  are  typical  TLS  examples  of 
selection  variable  definition. 

The  identification  of  selection  variables  within  a  system  is  usually 
straightforward.  These  are  simply  the  decision  parameters  whose  value 
determines  whether  one  series  of  processing  steps  or  an  alternative  is  to 
be  done.  When  multiple  message  types  pass  through  an  INPUT_INTERFACE,  the 
type  identifier  contained  in  the  message  is,  with  no  known  exceptions,  a 
selection  variable  (e.g., COMMANDED  In  the  CC_IN  interface  hierarchy).  Since 
the  data  input  to  an  ALPHA  Is  fixed,  and  since  each  message  type  implies 
either  different  data  content  or  different  processing,  there  must  exist 
at  least  one  unique  ALPHA  for  each  message  type. 

3.2.3  Entering  R_NETs  in  the  ASSM 

The  required  Information  about  each  R_NET  Is  Its  name,  enabling 
mechanism,  and  structure.  In  the  current  version  of  REVS,  names  assigned 
to  R_NETs,  SUBNETS,  and  ALPHAS  must  be  unique  within  the  first  eight 
characters.  For  all  other  RSL  elements,  names  must  be  unique  over  a 
field  cf  sixty  characters,  which  Is  the  maximum  name  length  allowed. 

The  enabling  mechanism  of  an  R_NET  Is  either  a  single  INPUT_INTERFACE 
or  a  single  EVENT.  If  a  message  passing  through  an  Interface  is  the  mecha¬ 
nism,  then  the  first  statement  In  the  R_NET  STRUCTURE  is  an  INPUTJNTERFACE 
name  declaration.  In  the  case  of  EVENT,  the  EVENT  name  does  not  appear  In 
the  STRUCTURE  of  the  enabled  R_NET.  However,  It  appears  in  the  STRUCTURE 
of  the  enabling  R_NET  at  the  appropriate  point. 

When  the  R_NET  Is  entered  Into  the  ASSM  via  card  input,  data  elements 
which  appear  In  the  STRUCTURE  must  be  predefined  In  the  ASSM.  These  data 
are  discussed  In  3.2.2.  The  R  NET  STRUCTURE  Is  discussed  in  3.2.4. 
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Figure  3-11  RSL  Data  Entry 


3.2.4  The  STRUCTURE  of  an  R_NET 

Flows  through  the  system  are  specified  in  RSL  as  Requirements  Networks 
(R  NETs).  R  NET  flow  STRUCTURES  consist  of  nodes,  which  specify  processing 
operations,  and  the  arcs  which  connect  them.  The  processing  nodes  are  ALPHAS, 
which  are  specifications  of  functional  processing  steps,  and  SUBNETS,  which 
are  specifications  of  processing  flows  at  a  lower  level  in  the  hierarchy. 

The  processing  nodes  are  single-entry,  single-exit. 

In  addition  to  the  simple  sequential  flow  which  may  be  represented  by 
connecting  this  type  of  node,  more  complex  flow  situations  are  expressible 
in  RSL  by  the  use  of  structured  nodes  which  fan-in  and  fan-out  to  specify 
different  processing  paths.  These  nodes  are  variations  of  AND  and  OR  nodes, 
and  include  an  OR  with  a  CONSIDER  statement.  The  REVS  Users  Manual  contains 
an  extensive  discussion  of  these  structural  elements  anu  should  be  reviewed 
by  the  new  user.  The  TLS  examples  in  the  appendices  of  this  volume  should 
also  be  studied  to  understand  the  format  of  ''arious  structures.* 


♦NOTE:  In  the  version  of  REVS  used  to  generate  this  document  there  were  two 
differences  between  acceptable  STRUCTURE  inputs  and  listed  outputs.  These 
concern  the  CONSIDER  and  FOR  EACH  statements.  In  each  case  the  element-type- 
names,  which  are  automatically  inserted  in  the  output,  must  be  omitted  in  the 
Input.  Where  the  output  list  would  read: 

CONSIDER  DATA:  MODE 

FOR  EACH  ENTITY _TYPE:  RETURNED_PULSE 
DO  ALPHA:  SUMMARIZEJJSAGE  END 

the  input  statements  must  read: 

CONSIDER  MODE 

FOR  EACH  RETURNED  PULSE 
DO  SUMMARIZEJJSFafc  END 

The  current  version  of  REVS  will  accept  inputs  in  either  format. 
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Indentation  is  used  in  the  STRUCTURE  declaration  to  facilitate  reading, 
hen  entering  the  declaration  on  cards,  using  REVS  in  the  offline  mode,  the 
user  should  follow  the  indentation  format  typified  by  the  REVS  output  exam¬ 
ples  in  the  appendices.  This  is  not  mandatory,  but  it  is  strongly  recommended 
in  order  to  check  the  output  against  the  Input.  In  this  way,  the  user 
can  quickly  detect  where  REVS  has  interpreted  the  STRUCTURE  in  a  different 
way  than  the  user  visualized. 

In  addition  to  describing  the  processing  flow  of  an  R_NET,  the  STRUC¬ 
TURE  declaration  may  also  serve  to  declare  the  existence  of  the  named  ALPHAS 
and  SUBNETS.  The  STRUCTURE  of  any  SUBNETS  should  also  be  declared  at  this 
time.  Further  definition  of  the  attributes  of  ALPHAS  will  take  place  in 
Phase  3. 

If  Anagraph  or  CALCOMP  plots  of  the  structures  are  desired,  graphic 
data  must  be  entered  for  each  R_NET.  Currently,  this  graphics  information 
can  only  be  entered  from  the  Anagraph  terminal.  The  Anagraph  plots  are 
useful  while  working  interactively  at  the  terminal.  The  CALCOMP  plots  are 
more  useful  for  permanent  retention,  and  for  documentation,  as  in  Appendix  D. 


3.2.5  Checking  the  Kernel  with  the  Aid  of  RADX 

As  part  of  the  auditing  process,  it  is  useful  here  to  define  a  set  of 
RADX  directives  which  assist  the  engineer  in  determining  the  completeness 
of  his  entries  into  the  ASSM  at  this  stage.  Two  operations  are  recommended 
which  are  simple,  but  revealing: 

1)  APPEND  R_NET  STRUCTURE,  ENABLED. 

LIST  R_NET. 

2)  APPEND  SUBNET  STRUCTURE,  REFERRED. 

LIST  SUBNET. 

These  directives  generate  a  listing  of  the  R_NETs  with  their  structures  and 
enabling  events  or  interfaces.  Clearly,  each  R_NET  requires  a  structure, 
and  an  enabling  condition,  and  any  failure  of  that  class  is  detectable  here. 
Similarly,  the  correctness  (agreement  with  intention)  of  EV^NT  naming  may 
be  confirmed. 
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While  it  is  possible  to  confirm  the  structures  by  inspection  of  the 
RADX  output,  most  people  find  reading  the  equivalent  diagrams  (generated 
by  RNETGEN)  simpler;  since  they  are  equivalent  representations,  either  the 
CALCOMP  illustration  or  the  RADX  listing  may  be  employed  for  the  purpose. 

(Note  that  viewing  the  Anagraph  output  at  the  terminal  is  less  useful  since 
all  element  names  are  truncated  to  three  characters  and  since  branching 
criteria  are  not  immediately  displayed.) 

It  is  in  data  analysis  that  the  RADX  tools  are  most  useful  at  this 
stage.  Let  us  define  two  hierarchies  for  data  output: 

HIERARCHY  FILES  =  FILE  CONTAINS  DATA  DATA  INCLUDES  DATA. 

HIERARCHY  DATUM  =  DATA  INCLUDES  DATA. 

Now,  we  wish  to  Identify  the  DATA  items  and  the  FILEs  which  are  not  linked 
with  higher  data  levels  (entities,  or  messages).  One  way  derives  from  the 
following  definitions: 

SET  A  =  ALL  WITHOUT  ASSOCIATED. 

SET  8  =  A  WITHOUT  MAKES. 

SET  C  =  B  WITHOUT  CONTAINED. 

SET  D  =  C  WITHOUT  INCLUDED. 

Now  the  RCL  (RADX)  directive:  LIST  B  WITH  HIERARCHY  FILES  will  generate 
both  the  file  names  and  the  data  comprising  each  such  file  where  the  file 
is  not  associated  with  an  entity  and  does  not  make  a  message.  Such  a  free¬ 
standing  file  should  be  a  conscious  product  of  requirements  engineering  and 
not  an  accident. 

Free-standing  DATA  may  be  extracted  by:  LIST  D  WITH  HIERARCHY  DATUM. 

Note  that  the  HIERARCHY  DATUM  is  used  here  as  a  convenience  to  limit  the 
output  to  the  names  of  the  top  data  level  not  constituting  part  of  a  hier¬ 
archy;  it  does  not  in  fact  cause  INCLUDED  DATA  to  be  output,  since  the  SET 
from  which  the  extraction  is  effected  (D)  has  no  members  which  are  INCLUDED 
In  any  DATA.  To  complete  tracing  of  the  data  hierarchies,  yet  another  SET 
would  have  to  be  defined  containing  the  DATA  extracted  by  LIST  D  WITH  HIER¬ 
ARCHY  DATUM,  and  that  SET  would  then  be  LISTed  with  HIERARCHY  DATUM. 

Typically,  free-standing  DATA  and  FILES  may  be  local  or  global  con¬ 
stants.  Each  item  extracted  by  the  methods  outlined  above  should  be  assessed 
to  determine  whether  in  fact  it  should  be  isolated  or  is  properly  a  constituent 
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of  an  entity  or  interface  hierarchy. 


Finally,  the  following  HIERARCHies  may  be  defined,  and  each  may  be 
used  to  complete  the  RADX  directive:  LIST  ALL  WITH  HIERARCHY  _ . 

HIERARCHY  ENTITY  = 

ENTITY_CLASS  ASSOCIATES  DATA 
ENTITY  CLASS  ASSOCIATES  FILE 
ENTITY_CLASS  COMPOSEP  ENTITY J'YPE 
ENTITY_TYPE  ASSOCIATES  DATA 
ENTITY_TYPE  ASSOCIATES  FILE 
FILE  CONTAINS  DATA 
DATA  INCLUDES  DATA. 

HIERARCHY  INFACE  = 

INPUTJNTERFACE  PASSES  MESSAGE 
MESSAGE  MADE  DATA 
MESSAGE  MADE  FILE 
FILE  CONTAINS  DATA 
DATA  INCLUDES  DATA. 

HIERARCHY  OUTFACE  = 

OUTPUTJNTERFACE  PASSES  MESSAGE 
MESSAGE  MADE  DATA 
MESSAGE  MADE  FILE 
FILE  CONTAINS  DATA 
DATA  INCLUDES  DATA. 

The  result  is  to  extract  from  the  ASSM  the  complete  kernel  of  the  require¬ 
ments,  as  illustrated  in  Appendix  C. 

3.2.6  Summary  of  Phase  2 

This  phase  has  been  a  period  of  consolidation,  between  the  initial 
definitions  of  Phase  1,  and  the  completion  of  those  definitions  in  Phase  3. 
Nonetheless,  the  end  of  Phase  2  is  an  important  milestone  in  the  total  effort. 

For  the  first  time,  the  kernel  of  the  requirements  construct  has  been 
loaded  into  the  ASSM  as  a  whole.  Many  of  the  early  mistakes  and  inconsis¬ 
tencies  will  be  detected  by  the  RSL  translator  during  the  entry  process. 

More  important,  the  requirements  engineer  can  now  use  the  facilities  of  the 
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Requirements  Analysis  and  Data  Extractor  (RADX)  to  aid  him  in  checking  his 
work. 

The  introductory  uses  of  RADX,  in  3.2.5,  will  be  built  upon  and  ex¬ 
panded  in  Phase  3.  Eventually,  the  user  will  compile  his  own  library  of 
RADX  procedures  he  values.  In  future  efforts  he  can  use  these  "off-the- 
shelf"  procedures  as  part  of  tin  evaluation  sequence  which  he  finds  most 
productive. 

3.3  PHASE  3  -  COMPLETION  OF  THE  FUNCTIONAL  DEFINITION 

The  work  through  Phase  2  has  provided  definition  of  the  higher-level 
elements  of  data  hierarchies;  definition  of  R_N£Ts,  their  STRUCTURES,  and 
their  enabling  events;  and  declaration  of  the  existence  of  ALPHAS  and  their 
place  in  the  R_NETs.  This  information  has  been  entered  into  the  ASSM  and 
has  been  subjected  to  some  form  of  checking. 

It  now  remains  to  complete  the  definition  of  these  elements  to  pro¬ 
vide  a  basis  for  construction  of  an  executable  simulation.  Each  ALPHA  must 
be  defined  in  terms  of  Its  data  transactions,  and  definition  of  all  DATA 
which  are  known  to  be  INPUT  TO  or  OUTPUT  FROM  an  ALPHA  must  be  completed. 

In  general,  the  DATA  which  can  be  described  at  this  stage  are  either  those 
global  to  multiple  R_NETs,  or  those  local  DATA  which  make  messages.  The 
need  for  additional  local  data  internal  to  the  R_NETs  will  be  discovered 
In  the  development  of  executable  descriptions  (Section  3.4).  At  that  time 
the  need  for  definition  of  lower  levels  of  the  existing  data  hierarchies 
may  be  apparent. 

During  this  process,  the  original  primitive  ALPHAS  will  often  need 
redefinition.  Additional  ALPHAS  can  be  added,  or  the  original  ALPHAS 
can  be  redefined  as  SUBNETS,  which  preserves  traceability  and  minimizes 
modification  of  the  R_NETs.  Occasionally,  the  STRUCTURE  of  the  net  may 
change,  or  new  nets  may  be  added,  as  the  processing  requirements  evolve. 

The  following  phase  will  be  devoted  to  construction  of  a  functional 
simulation,  using  BETAs,  which  are  executable  descriptions  of  the  ALPHAS. 

In  preparation,  the  user  should  bear  in  mind  that  he  Is  going  to  execute 
a  simulation  of  the  requirements  for  the  DPS  software,  and  not  of  the  soft¬ 
ware  Itself.  His  primary  goal  in  this  simulation  Is  to  ensure  that  the 
requirements  are  complete  and  consistent. 
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Since  the  major  interactions  of  the  R_NETs  have  been  defined  in  the 
previous  stages  (Sections  3.1  and  3.2),  it  is  now  practical  to  partition 
the  work  into  essentially  isolated  efforts  fot  several  engineers.  Eacti 
parcel  must  consist  of  one  or  more  RJiETs,  each  considered  by  a  single 
engineer  or  group.  Since  the  relationships  among  R_NETs  have  already  been 
defined,  the  interactions  among  parcels  will  be  restricted  to  joint  agree¬ 
ment  on  the  content  of  communications  (usually  individual  DATA)  between 
pairs  of  engineers,  and  need  not  be  coordinated  extensively  over  the 
system  as  a  whole.  The  sole  exception  to  that  rule  is  in  naming  conven¬ 
tions,  where  a  possibility  of  conflict  exists,  and  where  control  is  useful. 

3.3.1  Data  Transactions 

The  user  presumably  had  some  concept  of  the  DATA  which  were  to  be 
INPUT  TO  and  OUTPUT  FROM  each  ALPHA  when  he  named  the  ALPHA  and  placed  it 
in  the  STRUCTURE  of  an  R_NET.  After  all,  the  inputs  and  outputs  determine 
the  processing  needed  to  be  done  and  dictate  the  function  of  the  ALPHA. 

Now  the  gross  concept  must  be  precisely  defined.  During  this  process, 
additional  data  definitions  or  more  detailed  definition  of  existing  hier¬ 
archies  may  be  necessary. 

As  the  user  develops  the  data  transactions  and  the  hierarchy  transi¬ 
tions  discussed  in  3.3.3,  he  will  be  forced  to  consider  the  processing 
steps  within  each  ALPHA  which  transform  the  inputs  into  the  required  out¬ 
puts.  He  may  wish  to  note  his  conceptual  ideas  of  the  procedure  into  the 
ASSM,  in  English  text,  using  the  RSL  attribute  DESCRIPTION.  A  structured 
English  description  of  the  processing  can  later  be  used  for  reference  during 
development  of  the  BETAs  which  are  written  in  PASCAL.  If,  at  this  point, 
it  becomes  apparent  that  significant  logical  branching  must  occur  within 
the  ALPHA,  the  ALPHA  can  be  redefined  as  a  SUBNET.  In  this  manner  the 
logical  structure  requirements  are  made  explicit  in  the  STRUCTURE  definition 
of  the  SUBNET  and  new  ALPHAS  are  defined  to  specify  the  operations  within 
this  structure. 

As  an  example  of  the  thought  process  involved  with  data  transactions, 
consider  the  ALPHA  named  INITIATE_TRACK.  This  ALPHA  is  on  the  CC_RESPONSE 
R_NET  and  is  on  the  processing  path  activated  by  a  HANDOVER  message  of  type 
HAND0VER_ IMAGE  (=  COMMANDED).  Since  COMMANDED  was  used  as  a  selection 
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them  as  OUTPUT  FROM  the  ALPHA.  Figure  3-12  shows  the  declaration,  in  RSL, 
of  all  the  data  transactions  of  TRACK_INITIATE.  From  our  concept  of  the 
processing,  it  appears  that  the  original  ALPHA  is  adequate  and  no  additional 
ALPHAs,  or  redefinition  as  a  SUBNET,  are  required. 

3.3.2  RADX  Evaluation  of  Data  Transactions 

In  addition  to  confirming  entry  of  attributes  and  relationships  through 
RADX  directives  (e.g.,  LIST  ALPHA.),  it  is  now  useful  to  extract  the  specific 
cases  which  are  potential  errors,  or  are  at  least  anomalous  to  the  point 
where  they  demand  special  attention.  For  example,  it  is  possible  for  an 
ALPHA  either  to  have  no  INPUTS  or  to  have  no  OUTPUTS,  or  even  to  have  neither, 
without  its  being  erroneous;  but  the  normal  case  is  that  each  ALPHA  will  have 
both.  Having  completed  the  RSL  declarations  about  the  ALPHAS  at  this  stage, 
it  is  meaningful  to  define  the  following: 

1)  SET  A  =  ALPHA  WITHOUT  INPUTS. 

2)  SET  B  =  ALPHA  WITHOUT  OUTPUTS. 

3)  SET  C  =  A  WITHOUT  OUTPUTS. 

Remembering  that  the  declaration  of  a  SET  generates  a  count  of  its  members, 
we  may  discover  that  SET  C  is  empty;  that  would  indicate  that  each  ALPHA  has 
either  an  INPUTS  or  an  OUTPUTS  relationship  (or  both).  However,  in  TLS, 
several  ALPHAs  have  neither.  In  particular,  the  error-processing  elements 
are  required  to  exist,  but  have  no  other  specifications;  therefore,  they 
have  no  accesses  defined.  Similarly,  the  ALPHA: ACKNOWLEDGE  exists  solely 
so  that  the  ACKNOWLEDGEMENT  message  may  be  FORMED;  since  the  processing 
modifies  no  DATA,  the  ALPHA  has  neither  INPUTS  nor  0U1PUTS. 

In  general,  an  ALPHA  without  INPUTS  is  one  which  operates  on  the  sys¬ 
tem  as  a  whole,  rather  than  on  information  retained  by  the  DPS.  For  example, 
ENGAGEMENT^ NITIATION  and  TERM_ENGAGEMENT  accomplish  their  purposes  by  the 
occurrence  of  the  appropriate  message;  only  the  value  of  the  selection  var¬ 
iable  (COMMANDED)  is  required  to  initiate  them,  and  those  ALPHAs  execute 
independently  of  the  state  of  the  global  data  base. 

In  general,  an  ALPHA  with  INPUTS  but  without  OUTPUTS  is  a  signal  of 
a  specification  problem.  Trivially,  the  only  reason  for  acquisition  of  DATA 
for  processing  is  that  it  may  effect  some  generation  of  DATA  for  OUTPUT.  We 
have  not  yet  been  able  to  construct  a  valid  case  for  an  ALPHA  which  must 
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accept  INPUTS  but  is  not  required  to  provide  OUTPUTS. 

Since  the  work  described  in  3.3.3  and  3.3.4  often  proceeds  in  parallel 
with  that  of  3.3.1,  we  will  address  those  topics  at  this  point.  We  will 
return  to  a  more  detailed  look  at  RADX  evaluation  in  3.3.5. 

3.3.3  Hierarchy  Transitions 

In  addition  to  the  elementary  data  relationships,  each  ALPHA  may 
modify  DATA  within  hierarchies  in  a  variety  of  ways.  Given  the  engineer's 
concept  of  the  action  of  the  ALPHA,  it  is  possible  to  express  its  action  on 
the  hierarchies  in  terms  of  the  RSL  directives:  CREATES,  DESTROYS,  SETS, 
and  FORMS. 

There  are  two  fundamental  generative  operations  that  an  ALPHA  may 
express:  CREATES  and  FORMS.  They  declare  the  need  for  a  new  instance  of  a 
named  ENTITY_CLASS,  or  for  a  named  MESSAGE,  respectively.  In  response  to 
either  directive  it  is  required  that  the  specified  INITIAL_VALUEs  for  all 
associated  DATA  with  such  values  be  assigned.  This  is  done  automatically 
when  REVS  acts  upon  an  I N I T I AL_VAL UE  definition.  If  an  INITIALJ/ALUE  is 
not  defined,  REVS  will  assign  a  default  value  according  to  the  TYPE  of  the 
DATA.  These  values  are  (0,  0.0,  FALSE,  first  defined  value  in  the  RANGE) 
for  the  respective  types  (INTEGER,  REAL,  BOOLEAN,  ENUMERATION).  Once  the 
DATA  associated  with  the  instance  are  initialized,  they  may  be  assigned 
current  values  by  assignment  statements  within  the  BETA. 

When  an  instance  of  an  ENTITY_CLASS  is  CREATED,  it  will  normally  be 
SET  by  the  generating  ALPHA.  Otherwise,  only  the  DATA  and  FILEs  common  to 
all  types  in  the  class  can  be  defined.  As  the  instance  persists  in  the 
system,  its  type  will  evolve  (i.e.,  be  SET  to  a  different  type).  The  ALPHAS 
in  which  such  changes  are  effected  are  normally  obvious  from  the  R_NET.  In 
each  case,  such  an  ALPHA  SETS  ENTITY  TYPE  to  the  appropriate  ENTITY_TYPE 
name. 

For  example,  the  discussion,  in  3.3.1,  of  the  ALPHA  named  TRACK_ 
INITIATE  revealed  that  the  ALPHA  performs  all  of  the  actions  above.  It 
FORMS  the  MESSAGE  named  TRACK INITIATION .  Also,  it  first  CREATES  an  in¬ 
stance  of  ENTITYjCLASS  IMAGE,  then  SETS  the  instance  to  ENTITY_TYPE  IMAGE_ 
IN  TRACK.  Figure  3-13  shows  how  these  declarations  are  written  in  RSL. 
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When  there  is  no  further  need  for  the  DPS  to  retain  data  related  to  a 
specific  instance  of  an  ENTITY__CLASS,  or  to  be  aware  of  the  existence  of  the 
instance  in  the  external  world,  the  (instance  of  the)  ENTITY_CLASS  can  be 
DESTROYED  BY  an  ALPHA.  The  disposition  of  a  PULSE  in  the  TLS  depends  on 
whether  it  is  a  LOST_PULSE  or  a  RETURNED_PULSE.  For  a  LOST_PULSE,  the 
instance  is  DESTROYED  (no  longer  needed)  after  it  has  been  accounted  for 
in  the  ALPHA  named  ALLOCATE_AND_CONTRQL_RESOURCES.  For  a  RETURNED_PULSE , 
the  instance  is  not  destroyed  until  it  has  also  been  accounted  for  in  the 
ALPHA  named  SUMMARIZE  USAGE.  Note  that,  in  this  case,  the  instance  of 
PULSE  can  be  DESTROYED  in  either  of  the  two  ALPHAS,  but  not  before  it  has 

i 

been  accounted  for  in  both.  This  ip  because  the  RNETs  in  which  the  ALPHAs 
reside  execute  independently  of  one.another,  and  no  specific  sequence  is 
otherwise  required. 

3.3.4  Further  Data  Definition 

Through  the  previous  work  many,  if  not  most,  of  the  DATA  in  the  system 
have  been  named,  and  their  relationships  with  ALPHAS  have  been  established. 
In  order  to  complete  the  requirements  specification  and  construct  an  execut¬ 
able  simulation,  however,  the  "attributes"  of  the  DATA  must  be  defined. 

The  three  principal  attributes  are  LOCALITY,  TYPE,  and  USE.  In 
general,  the  user  will  have  a  fair  idea  of  these  properties  when  he  first 
declares  the  DATA  element.  His  concept  is  further  sharpened  when  he  sees 
how  the  ALPHAs  utilize  the  DATA. 

3. 3.4.1  Locality 

DATA  and  FILES  may  have  different  required  accessibility  in  the  sys¬ 
tem.  The  range  of  accessibility  of  an  item  is  denoted  by  the  attribute 
LOCALITY,  which  may  have  values  of  LOCAL  or  GLOBAL.  Items  of  DATA  or  FILEs 
which  are  LOCAL  are  associated  with  the  R_NETs  in  which  they  are  used  and 
are  unknown  outside  of  these  R_NETs.  Implicit  in  this  definition  is  a  con¬ 
cept  of  permanence:  LOCAL  DATA  exist  only  during  the  invocation  of  the 
R  NET  to  which  they  are  LOCAL.  They  are  created  when  the  flow  token  is 
generated  at  R_NET  ENABLEment  and  cease  to  exist  when  the  flow  token  leaves 
that  R_NET.  ALPHAs  which  use  LOCAL  DATA  and  FILEs  may  appear  on  more  than 
one  R_NET;  it  is  possible  for  a  single  DATA  item  or  a  FILE  to  be  LOCAL  to 
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more  than  one  R_NET.  These  are  different  instances  of  the  DATA  or  FILE 
which  have  no  relation  to  each  other,  each  has  a  completely  separate  exis¬ 
tence,  controlled  by  the  R_NET  in  question. 

GLOBAL  DATA  and  FILES  are  accessible  by  more  than  one  R_NET  and  exist 
over  more  than  one  R_NET  invocation.  DATA  and  FILEs  which  are  ASSOCIATED 
with  an  ENTITY_TYPE  or  an  ENTITY_CLASS  are  tied  to  the  entity  instances  to 
which  they  belong.  They  are  created  when  the  Instance  is  CREATED  and  last 
until  the  instance  is  DESTROYED.  Items  which  are  not  ASSOCIATED  with  any¬ 
thing  are  permanently  in  the  global  data  base,  and  may  exist  throughout  the 
duration  of  the  system. 

Thus,  DATA  and  FILEs  which  belong  to  an  Interface  data  hierarchy  are 
implicitly  LOCAL.  DATA  and  FILEs  associated  with  an  entity  data  hierarchy 
are  Implicitly  GLOBAL.  DATA  and  FILEs  not  associated  with  either  type  of 
hierarchy  have  no  implicit  locality.  Even  if  the  locality  is  not  explicitly 
defined,  an  item  exists  In  the  data  base  at  all  times,  accessible  to  the 
R_NETs,  but  In  an  "undefined"  state.  Failure  to  declare  LOCALITY  can  pro¬ 
duce  weird  consequences  later,  if  the  element  involved  has  no  implicit 
locality.  On  the  other  hand,  declarations  are  not  needed  if  the  locality 
Is  implicit.  At  best  they  are  redundant,  and  at  worst  they  are  misleading 
because  REVS  overrides  any  declaration  in  the  ASSM  which  conflicts  with  the 
Implicit  locality. 

While  the  user  may  clearly  Identify  which  DATA  and  FILEs  need  LOCALITY 
declarations,  and  which  do  not,  it  is  easier  and  less  risky  to  use  a  RADX 
procedure  to  do  this.  One  such  procedure  Is  discussed  in  3.3.5. 

For  the  remaining  items  which  need  a  LOCALITY  declaration,  the  user 
should  consider  the  source  of  the  Item.  If  an  Independent  DATA  Item  or  FIlE 
Is  not  OUTPUT  FROM  some  ALPHA  on  an  R_NET  previous  to  its  being  INPUT  TO 
some  other  ALPHA  on  that  net,  It  certainly  cannot  be  LOCAL  to  that  R_NET. 

If  the  item  Is  OUTPUT  FROM  an  ALPHA  on  some  other  R_NET,  the  Item  Is  cer¬ 
tainly  GLOBAL  unless  an  error  has  been  made  in  the  INPUTS  and  OUTPUTS  defi¬ 
nitions.  In  many  cases  the  correct  locality  is  obvious.  The  Inability  to 
find  a  source  for  an  Independent  Item  on  any  of  the  R_NETs  indicates  a 
specification  deficiency. 
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If  a  DATA  item  or  FILE  is  OUTPUT  FROM  an  ALPHA  on  a  net  other  than 
that  which  uses  the  item  as  input,  the  indicated  LOCALITY  is  GLOBAL.  If 
no  other  R_NET  generates  the  item,  then  the  origin  of  the  item  is  on  a 
previous  execution  of  the  R_NET  which  uses  it. 

If  the  ALPHA  which  OUTPUTS  an  item  does  not  clearly  precede  the  ALPHA 
which  INPUTS  it,  care  must  be  taken  to  ensure  that  the  item  has  an  initial 
value.  The  default  values  assigned  by  REVS  in  the  absence  of  an  INITIAL 
VALUE  declaration  were  described  in  3.3.3.  If  these  are  unacceptable,  the 
user  must  declare  the  correct  I N I T I AL  VAL UE .  Note  that  "clearly  precede" 
in  the  context  above  means  that  the  ALPHA  which  OUTPUTS  the  item  is  either: 

1)  before  the  ALPHA  which  INPUTS  it,  on  the  same  path  within  an  RNET,  or 

2)  precedes  the  ALPHA  which  INPUTS  the  item  on  a  single  path  linked  by 
enabling  EVENTs. 

3. 3.4.2  Type  and  Range 

Other  details  about  DATA  must  be  known  for  purposes  of  sinulation. 

BETAs  and  GAMMAs  are  executable  code  which  are  meaningful  only  if  more  is 
known  about  the  DATA  than  should  be  stated  as  a  requirement.  In  addition, 
a  hierarchy  of  DATA  may  be  stated  as  a  requirement,  but  a  functional  simu¬ 
lation  (using  BETAs)  may  employ  DATA  only  part  way  down  the  hierarchy.  That 
is,  the  simulation  may  use  one  DATA  to  represent  a  part  of  an  entire  hier¬ 
archy.  The  characteristics  of  this  summarized  DATA  must  be  stated  for  the 
simulation  to  execute.  Since  an  analytic  emulation  (using  GAMMAs)  might 
not  employ  the  same  DATA,  the  type  information  for  BETAs  may  be  different 
from  that  for  GAMMAs.  The  only  DATA  that  can  be  used  in  the  BETAs  and 
GAMMAs  and  have  their  values  communicated  between  ALPHAS,  however,  are  those 
whose  TYPE  has  been  defined. 

The  attribute  TYPE  contains  the  necessary  information  for  typing  of 
the  DATA.  This  attribute  may  have  values  REAL,  INTEGER,  BOOLEAN,  or  ENUMERA¬ 
TION.  A  DATA  item  with  type  enumerated  corresponds  closely  to  one  with  a 
scalar  type  in  PASCAL;  that  is,  it  has  values  which  are  denoted  by  identi¬ 
fiers.  The  legal  values  for  ENUMERATION  types  are  given  in  the  RANGE  attribute. 


The  TYPE  declared  need  not  correspond  to  that  of  the  actual  data  in 
the  real  DPS.  Rather,  It  should  be  chosen  to  reflect  the  purposes  of  the 
functional  and  analytic  simulations,  and  the  fidelity  required  in  those 
simulations.  For  instance,  in  the  real  DPS,  unique  alphanumeric  text  strings 
may  be  used  to  identify  objects.  If  these  are  an  open  set,  we  cannot  repre¬ 
sent  them  by  a  DATA  element  with  TYPE:  ENUMERATION  because  that  defines  a 
closed  set.  However,  for  purposes  of  simulation,  the  DPS  property  of  interest 
is  the  ability  of  the  DPS  to  distinguish  between  unique  identifiers.  Thus, 
by  defining  the  identifier  as  TYPE:  INTEGER,  and  representing  each  object 
or  class  of  objects  by  a  unique  integer  value,  we  have  an  adequate  repre¬ 
sentation  for  our  purposes. 

Similarly,  in  TLS,  identifiers  such  as  H0_ID,  IMAGE_ID,  and  RADAR_ 
0RDER_ID  are  represented  by  integers.  In  the  real  TLS  some  symbolic  code 
convention,  which  is  Irrelevant  to  us  at  this  stage,  would  be  used.  In 
like  fashion,  message  identifiers  such  as  COMMANDED  which  form  a  closed 
set  are  represented  as  DATA  with  TYPE:  ENUMERATION.  The  values  defined 
are  for  explanatory  purposes.  The  values  in  the  actual  TLS  would  certainly 
be  different. 

Since  the  appropriate  TYPE  for  DATA  is  strongly  dependent  on  its  USE, 
the  choice  may  be  deferred  until  the  USE  has  been  determined. 

3.3.4. 3  Use 

Further  qualification  of  the  use  of  a  DATA  item  in  the  simulation 
is  given  by  the  attribute  USE.  The  value  of  this  attribute  may  be  BETA, 

GAMMA,  or  BOTH  denoting  that  the  data  item  is  the  lowest  level  in  the  data 
hierarchy  which  will  be  used  in  the  corresponding  simulation. 

Frequently,  even  the  first  declaration  of  a  DATA  item  makes  clear 
Its  USE  in  the  system.  For  example,  if  the  element  is  known  to  correspond 
to  a  single  unit  of  information  (bit,  byte,  or  word)  in  implementable  soft¬ 
ware,  then  It  Is  probably  to  be  used  in  BOTH  beta  and  gamma  models.  Nor¬ 
mally,  a  selection  variable  will  be  In  this  class.  Similarly,  It  Is  likely 
that  an  Item  which  INCLUDES  others  In  the  detailed  modeling,  but  which  may 
be  treated  as  a  whole  for  functional  modeling  will  have  USE:BETA.  It  is 
unlikely  that  any  element  with  USE  restricted  to  GAMMA  will  oe  recognized 
at  this  stage  of  development,  since  its  declaration  would  be  primarily  in 
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support  of  analytic  simulation;  the  exception  would  occur  if  a  highly  de¬ 
tailed  interface  specification  gave  low-level  DATA  definitions,  for  which 
higher  levels  would  suffice  in  a  functional  model. 

For  example,  in  the  TLS  definition,  INITIAL_$TATE  is  a  single  DATA 
element  with  USE:BETA.  In  the  external  world  "state"  is  defined  by  a  posi¬ 
tion  vector,  a  velocity  vector,  and  perhaps  an  acceleration  vector,  each 
with  three  components.  Such  detail  is  not  needed  for  the  functional  simu¬ 
lation.  However,  an  analytical  simulation  has  need  for  these  elements. 

Thus,  eventually  each  of  the  components  will  be  defined,  with  USE: GAMMA. 
Similarly,  for  the  functional  simulation,  IN ITIALCOVARIANCE  can  be  repre¬ 
sented  by  a  single  element  with  USE : BETA .  Later,  its  matrix  components  can 
be  defined  with  USE:GAMMA  when  they  are  needed  for  analytic  simulation. 

3. 3. 4. 4  Values 

Values  are  the  ultimate  object  of  defining  DATA.  At  the  lowest  level 
in  a  hierarchy  of  DATA  the  requirements  engineer  may  specify  the  attributes 
UNITS,  MAXIMUM JALUE,  MINIMUMJALUE,  INITIAL  JALUE,  and  RESOLUTION.  The 
attribute  UNITS  is  given  separately  from  the  various  types  of  values,  both 
to  maintain  consistency  with  their  specification  and  to  enable  requirements 
engineers  to  indicate  the  minimum  possible  information  about  a  DATA'S  value, 
its  UNITS.  In  nearly  all  cases  an  engineer  will  know  whether  he  is  talking 
about  milliseconds  or  microseconds  even  if  he  is  unsure  of  the  value.  Sepa¬ 
rating  UNITS  from  the  values  enables  him  to  provide  the  best  information  that 
he  has  at  the  initiation  of  defining  a  DATA  item. 

Since  the  attribute?  UNITS,  MAXIMUMJ/ALUE,  MINIMUMJALUE,  and  INITIAL_ 
VALUE  are  not  vectors,  the  definition  of  different  UNITS  and  values  of  a  DATA 
set  above  the  lowest  level  in  the  hierarchy  is  not  possible.  RESOLUTION 
describes  the  required  maximum  value  of  the  least  significant  bit  for  the  DATA 
in  units  described  in  the  UNITS  attribute. 

3.3.5  Evaluation  of  the  ASSM  Using  RADX 

The  Requirements  Analysis  and  Data  Extraction  (RADX)  function  of  REVS 
is  the  tool  used  by  the  requirements  engineer  to  observe  the  state  of  the 
Abstract  System  Semantic  Model.  RADX  provides  commands  that  allow  the  per¬ 
formance  of  several  functions: 
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•  identification  and  listing  of  elements  in  the  ASSM  that  do 
or  do  not  meet  some  criterion. 

•  listing  of  ASSM  elements  in  such  a  manner  as  to  be  suitable 
for  inclusion  in  requirements  documents. 

•  listing  of  RSL  element,  attribute,  and  relation  definitions. 

•  analysis  of  the  ASSM  to  identify  requirements  that  are 
ambiguous  or  inconsistent. 

The  requirements  engineer  should  actively  use  RADX  to  extract  specific 
data  for  analysis  and  to  detect  inconsistencies  and  omissions  in  the  ASSM. 

This  capability  is  also  used  by  technical  managers  to  evaluate  progress  of 
the  development  activity,  and  by  independent  analysts  who  may  be  assigned 
to  verify  the  work  af  the  requirements  engineer. 

The  following  subparagraphs  discuss  typical  uses  of  RADX  in  evaluating 
the  work  done  in  Phase  3,  and  in  identification  of  work  remaining  to  be  done. 
These  examples  are  not  meant  to  be  comprehensive,  nor  are  they  the  only  way 
to  do  the  task.  A  comprehensive  catalog  of  RADX  procedures  would  be  a  very 
thick  document,  and,  there  are  many  ways  to  do  a  specific  extraction  task 
effectively.  Other  examples  can  be  found  in  the  REVS  Users  Manual.  Our 
purposes  here  are  merely  to  suggest  some  of  the  uses  of  RADX,  and  to  encourage 
the  user  to  creatively  use  these  facilities  in  his  work. 

3. 3. 5.1  RADX  Evaluation  of  Data  Origin  and  Usage 


A  DATA  item  may  be  entered  into  the  data  base  in  any  of  the  following 

ways: 

1)  It  may  be  OUTPUT  BY  an  ALPHA; 

2)  It  may  be  INCLUDED  IN  a  DATA  OUTPUT  BY  an  ALPHA; 

3)  It  may  be  CONTAINED  IN  A  FILE  OUTPUT  BY  an  ALPHA;  or 

4)  It  may  MAKE  a  MESSAGE  which  is  PASSED  BY  an  INPUTJNTERFACE. 

(Let  us  include  in  the  last  category  DATA  INCLUDED  in  DATA  which  MAKES  such 
a  MESSAGE  and  DATA  CONTAINED  IN  a  FILE  which  MAKES  such  a  MESSAGE.) 

We  wish  to  extract  exceptions  to  the  above  rules,  since  they  consti¬ 
tute  apparent  cases  of  'creative  memory'  —  data  extractable  from  the  global 
data  base  which  never  need  to  be  entered.  An  obvious  and  legitimate  case  of 
creative  memory  Is  a  constant  with  a  defined  INITIAL_VALUE;  in  fact,  DATA 
constants  are  properly  defined  in  just  such  a  manner.  But  any  non-constant 
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data  item  which  fits  in  none  of  the  above  categories  is  an  apparent  error, 
and  worthy  of  detailed  analysis.  (Note  that  a  DATA  element  which  is  never 
INPUT  TO  an  ALPHA  and  which  does  not  MAKE  a  MESSAGE  which  is  PASSED  BY  an 
OUTPUT  INTERFACE  is  also  worthy  of  scrutiny,  and  may  be  similarly  analyzed 
at  this  itage.  Among  the  DATA  which  will  properly  be  detected  at  this  step 
are  those  REFERRED  by  an  R_NET--  e.g.,  selection  variables.) 

With  the  aid  of  the  hierarchy  definitions  in  3.2.5  we  can  construct 
RADX  procedures  to  isolate  the  DATA  described  above.  First  we  will  define 
RADX  commands  which  are  used  in  both  cases: 

SET  INALPH  -  DATA  THAT  IS  INPUT  BY  ALPHA. 

SET  OUTALPH  =  DATA  THAT  IS  OUTPUT  BY  ALPHA. 

The  additional  commands  below  will  provide  a  listing  of  DATA  INPUT  TO 
an  ALPHA  which  does  not  have  an  INITIAL  VALUE,  and  is  not  in  a  MESSAGE 
PASSED  BY  an  INPUT  INTERFACE,  and  which  is  not  OUTPUT  FROM  some  ALPHA  on 
some  RNET. 

SET  INMSG  =  ALL  IN  HIERARCHY  I Nr ACE. 

SET  INDATA  =  INMSG  AND  DATA. 

SET  INOUT  =  INALPH  MINUS  OUTALPH. 

SET  INOUT  =  INOUT  MINUS  INDATA. 

SET  INOUT  =  INOUT  WITHOUT  INITIALJ/ALUE. 

LIST  INOUT  WITH  HIERARCHY  DATUM. 

If,  instead,  we  use  the  commands  below,  we  will  get  a  listing  of  DATA 
which  is  OUTPUT  from  an  ALPHA  and  not  INPUT  TO  an  ALPHA  and  not  in  a  MESSAGE 
PASSED  BY  an  OUTPUT  INTERFACE. 

SET  OUTMSG  =  ALL  IN  HIERARCHY  OUTFACE. 

SET  OUTDATA  =  OUTMSG  AND  DATA. 

SET  OUTIN  =  OUTALPH  MINUS  INALPH. 

SET  OUTIN  =  OUTIN  MINUS  OUTDATA. 

LIST  OUTIN  WITH  HIERARCHY  DATUM. 

Doubtlessly,  the  imaginative  user  can  invent  more  efficient  and 
powerful  procedures  to  do  the  same  task,  as  well  as  others  which  investi¬ 
gate  other  aspects  of  data  usage.  The  flexibility  of  RADX  command  capa¬ 
bility  allows  many  valid  approaches  to  the  same  goal. 


3 . ' i .  5 .  2  RAUX  Eva  1  uat i o n  of  Fi  1  o  Act!  vi  ty 

In  3.3.1  we  dis_  .ssed  the  i nterpretations  to  be  made  when  a  FILE  is 
INPUT  TO  and/or  OUTPUT  f-ROM  an  A.PHA .  RAUX  commands  can  be  used  to  isolate 
various  INPUT/OUTPUT  combinations  for  verification.  The  following  are 
useful  . 

SET  A  =  FILE  WITH  INPUT. 

SlT  B  -  FILE  WITH  OUTPUl. 
jLT  C  A  OR  b. 

SET  IJ  =  FILE  MINUS  U. 

SLT  L  =  B  MINUS  A. 

SET  I  =  A  MINUS  B. 

SET  fi  =  A  AND  B. 


Set  iJ  consists  ol  FILEs  which  are  neither  INPUT  TO  nor  OUTPUT  FROM  an 

f  1  PHA . 

set  L  consists  of  I  ILL’S  which  are  only  OUTPUT  FROM  some  ALPHA.  We  can 
assu:  c  that  additions  were  made  to  trie  FILL  for  some  purpose.  The  only  valid 
purpose,  other  than  for  INPUT  TO  some  ALPHA,  is  to  MAKE  an  output  MESSAGE. 

The  following  RAUX  commands  provide  a  listing  of  the  remainder  which  do  not 
MAKE  an  output  MtSSAGt  and  which  should  be  checked  for  errors. 

SET  h  =  E  MINUS  OUTMSG. 

LIST  II. 

Set  F  consists  of  FILLs  which  are  only  INPUT  TO  some  ALPHA.  This  indi¬ 
cates  that  the  FILE  instances  are  accessed,  and  possibly  deleted,  within  the 
ALPHA.  -  Since  the  FILE  is  not  OUTPUT  FROM  an  ALPHA,  it  cannot  originate  with¬ 
in  the  DPS.  Therefore,  it  must  appear  in  an  input  MESSAGE.  The  following 
RAUX  commands  provide  a  listing  of  the  remainder  which  do  not  MAKE  an  input 
MESSAGE  and  which  should  be  checked  for  errors. 

SLT  I  =  F  MINUS  INMSG. 

LIST  I. 

Set  G  consists  of  FILEs  which  are  both  INPUT  TO  and  OUTPUT  FROM  some 
mLPHAs,  not  necessarily  the  same  ALPHA.  These  FILEs,  together  with  the 
ALPHAs  which  operate  on  them,  can  be  extracted  by  the  following  commands. 
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APPEND  FILE  INPUT,  OUTPUT. 
LIST  G. 


This  listing  should  be  examined  to  ensure  that  the  FILEs  are  operated 
upon  as  intended.  Particular  attention  should  be  paid  to  ALPHAS  which  both 
INPUT  and  OUTPUT  the  same  FILE.  It  is  these  ALPHAS  which  either  modify  the 
instances  within  a  FILE,  or  add  new  instances  when  an  appropriate  one  cannot 
be  found. 


3 .3. 5. 3  RADX  Evaluation  of  Entity  Activity 

It  is  also  useful  to  verify  that  ENTITY_CLASSes  and  ENTITY_TYPEs  are 
manipulated  appropriately  within  the  system.  Each  ENTITY  CLASS  must  be 
CREATED  BY  some  ALPHA.  Each  ENTITY_CLASS  should  be  DESTROYED  BY  some  ALPHA. 
If  it  is  not  destroyed,  there  must  be  a  valid  reason  for  retaining  the  asso¬ 
ciated  data.  Further,  each  ENTITY_TYPE  within  an  ENTITY_CLASS  must  be  SET  BY 
some  ALPHA.  The  members  of  the  following  sets  are  apparent  deviations  and 
should  be  examined. 

SET  A  =  ENTITY_CLASS  WITHOUT  CREATED. 

SET  B  =  ENTITYjCLASS  WITHOUT  DESTROYED. 

SET  C  =  ENTITY  TYPE  WITHOUT  SET. 

The  following  hierarchy  is  useful  to  determine  the  actions  on  each 
ENTITY_CLASS  in  the  system. 

HIERARCHY  ENTITY_CHECK  = 

ENTITYJCLASS  CREATED  BY  ALPHA 

ENTITY  JCLASS  COMPOSED  ENTITY_TYPE 
ENTITYTYPE  SET  BY  ALPHA 

ENTITYJCLASS  DESTROYED  BY  ALPHA. 

The  following  RADX  command  will  provide  a  structured  listing  of  each 
instance  of  the  hierarchy  suitable  for  further  analysis. 

LIST  ALL  WITH  HIERARCHY  ENTITYJCHECK. 

3. 3.5.4  RADX  Evaluation  of  Data  Attributes 

Data  extraction  can  be  of  major  support  in  development  of  the  execut¬ 
able  description,  although  it  is  not  a  major  contributor  to  assessment  of 
the  result.  The  fact  that  RADX  cannot  penetrate  the  contents  of  a  BETA  to 
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determine  its  consistency  with  declarations  of  relationships  and  attributes 
is  of  little  significance,  since  the  consistency  and  completeness  are 
thoroughly  analyzable  with  the  static  analyzers,  and  since  the  crucial  test 
of  simulation  generation  is  then  executable. 

One  of  the  key  operations  at  this  stage  of  specification  development 
is  defining  the  LOCALITY,  USE,  and  TYPE  of  all  DATA  required  for  functional 
simulation.  LOCALITY  is  the  easiest  of  the  attributes  to  specify: 

1)  Using  the  definitions  of  3.2,  LIST  ALL  WITH  HIERARCHY 
ENTITY  generates  a  collection  of  GLOBAL  DATA; 

2)  Using  those  definitions,  LIST  ALL  WITH  HIERARCHY  INFACE  and 
LIST  ALL  WITH  HIERARCHY  OUTFACE  generates  a  collection  of 
LOCAL  DATA; 

3)  LIST  B  WITH  HIERARCHY  FILES  generates  the  collection  of 

DATA  CONTAINED  IN  FILEs  which  are  not  linked  to  higher  levels. 
Since  each  such  file  is  inherently  either  local  or  global  in 
scope,  all  CONlAINED  DATA  have  the  same  LOCALITY  as  their 
parent;  and 

4)  LIST  D  WITH  HIERARCHY  DATUM  identifies  the  top  level  of 
DATA  which  are  not  linked  into  higher  levels.  Each  such 
item  is  then  assigned  a  LOCALITY,  which  is  also  the  value 
assigned  to  any  DATA  item  INCLUDED  in  that  top  level. 

Since  the  system  provides  an  override  of  any  LOCALITY  declaration  for  ASSO¬ 
CIATED  DATA  or  those  which  MAKE  a  MESSAGE,  any  LOCALITY  provided  by  the  user 
would  be  at  least  redundant,  and  at  worst  misleading.  Therefore,  it  is 
recommended  that  each  DATA  item  and  FILE  generated  by  (1)  and  (2)  above  be 
checked  to  ensure  that  no  LOCALITY  is  declared.  Similarly,  it  is  best  to 
declare  the  LOCALITY  for  each  FILE  derived  from  (3),  and  then  to  omit  LOCALITY 
for  each  DATA  item  obtained.  Finally,  each  DATA  item  obtained  in  (4)  is 
assigned  a  LOCALITY,  and  the  same  LOCALITY  is  assigned  to  each  DATA  item 
included  in  it. 

Data  extraction  also  supports  assigning  USE  to  the  DATA  items.  Define 
SET  A  =  DATA  WITHOUT  INCLUDES.  Each  item  in  that  set  must  have  USE  GAMMA 
or  BOTH.  It  is  given  USE  BOTH  exactly  if  it  is  to  be  a  part  of  the  BETA 
model  of  some  ALPHA.  For  each  item  with  USE: BOTH,  no  DATA  above  it  in  the 
hierarchy  can  have  a  USE  assigned.  Note  that  USE:B0TH  and  USE:GAMMA  may 
be  applied  only  to  the  lowest  level  of  DATA  defined.  Once  it  is  determined 
that  a  given  lowest-level  DATA  item  will  not  be  included  in  the  functional 
model,  an  item  above  it  in  the  hierarchy  must  be  assigned  USE:BETA.  That 
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item  may  be  anywhere  above  the  one  with  USE: GAMMA,  except  that  it  cannot 
also  INCLUDE  (either  directly  or  through  a  chain  of  INCLUDES)  any  element 
with  USE: BOTH. 

By  defining  a  SET  A  =  DATA  WITH  USE,  the  engineer  determines  the  items 
requiring  TYPE.  It  is  not  mandatory  at  this  stage  to  TYPE  DATA  which  are  to 
be  used  only  analytically,  so  that  the  subset  required  for  functional  simu¬ 
lation  can  be  obtained  through  SET  B  =  A  WITHOUT  USE  =  GAMMA.  Through 
examination  of  the  STRUCTURES  and  BETAs,  the  TYPE  of  each  such  item  is 
defined,  and  enumeraced  DATA  are  also  assigned  RANGE. 

Note  that  it  is  at  least  misleading,  and  sometimes  likely  to  induce 
errors,  to  define  attributes  for  elements  which  do  not  require  them.  Thus, 
a  LOCALITY: LOCAL  declaration  for  an  item  ASSOCIATED  WITH  an  ENTITY  TYPE 
would  he  overridden  by  REVS,  but  would  be  entered  into  the  ASSM  and  would 
appear  to  the  reader  of  the  specification  to  control  the  DATA  item.  Such 
a  condition  would  clearly  degrade  legibility  of  the  document,  and  should 
be  avoided.  The  data  extractor  can  be  used  to  determine  if  any  over- 
specification  of  this  sort  has  been  attempted.  (Note  .hat  the  ASSM  for 
TLS  as  documented  in  the  Appendices  includes  such  cases.  At  the  time  of 
it:  development,  the  capabilities  of  the  extractor  were  more  limited  than 
at  present,  and  manual  methods  were  employed  to  complete  the  data  base.) 

3.3.6  Summary  of  Phase  3 

This  section  has  outlined  a  general  procedure  for  completing  the 
definition  of  the  functional  requirements  for  a  DPS.  The  following  steps 
were  done: 

•  The  data  transactions  of  each  ALPHA  were  defined. 

•  The  hierarchy  transitions  performed  hy  each  ALPHA,  if 
any,  were  defined. 

•  The  user  has  redefined  ALPHAS  into  SUBNETS,  has  added 
ALPHAS,  and  has  modified  R  NET  STRUCTURES  if  the  Phase 
2  baseline  was  inadequate. 

•  The  user  has  evolved  a  clear  concept  of  the  processing 
done  within  each  ALPHA,  as  a  starting  point  for  develop¬ 
ment  of  BETAs. 

•  The  definition  of  all  necessary  DATA  and  FILE  attributes 
has  been  completed,  to  the  extent  possible  without 
developing  BETAs  and  GAMMAs. 


•  The  completeness  and  consistency  of  the  ASSM  has  been 
analyzed  and  verified  with  the  aid  of  RADX  capabilities. 

We  have  reached  another  milestone.  The  definition  of  the  functional 
requirements  is  hypothetically  complete.  In  Phase  4  we  will  develop  the 
executable  simulation  needed  to  verify  that  assertion. 

3.4  PHASE  4  -  DEVELOPMENT  OF  FUNCTIONAL  MODELS 

Specification  of  the  functional  requirements  entails  development  of 
functional  models  which  define  the  outputs  of  processing  in  terms  of  its 
inputs.  In  essence,  the  only  things  known  to  a  data-processor  specifica¬ 
tion  are  the  contents  of  its  interface  messages;  all  other  information 
should  be  defined  within  the  specification  in  terms  of  mathematical  opera¬ 
tions  on  the  input  data  stream.  Such  a  definition  is  in  effect  a  model 
of  the  processing  operations  required,  and  with  sufficient  fidelity  would 
provide  the  analytic  models  of  Section  4.  Where  the  model  reflects  only 
the  gross  characteristics  of  the  transformation  required,  It  may  be 
said  to  be  functional;  such  models  in  REVS  are  termed  BETAs.  The  BETA  and 
GAMMA  representations  of  the  DPS  must  be  driven  by  a  system  level  simulator 
which  SREM  assumes  to  exist,  due  to  the  prior  need  for  such  a  simulator  in 
deriving  the  originating  specifications.  The  TLS  example  presumes  exis¬ 
tence  of  a  System  Environment  and  Threat  Simulator  (SETS). 

3.4.1  Betas 

A  BETA  is  a  PASCAL  procedure  which  models  the  transformation  of  the 
DATA  ani  FILEs  INPUT  10  an  ALPHA  into  the  DATA  and  FILES  OUTPUT  FROM  it. 

The  function  of  a  BETA  is  to  implement  the  data  flow  required  for  func¬ 
tional  simulation  in  order  to  determine  the  sufficiency  of  a  functional 
specification.  To  that  end,  the  fidelity  of  each  BETA  is  dependent  on  the 
capabilities  required  of  the  functional  simulator,  and  in  particular  on  the 
data  contents  determined  for  SETS. 

Generation  of  a  BETA  is  more  or  less  creative  depending  on  the  fidelity 
desired.  At  the  simplest  level,  assignment  statements  may  be  employed  in 
place  of  complex  mathematical  operations.  In  TLS,  the  ALPHA:  UPDATEJSTATE 
is  modeled  by  assigning  to  STATE  (a  DATA  item  ASSOCIATED  WITH  ENTITY_TYPE 
IMAGt_I N  TRACK)  the  value  of  the  DATA  returned  by  SETS.  In  an  analytic 
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model,  the  equivalent  operation  would  be  execution  of  a  high-order  Kalman 
filter.  The  simple  model  is  appropriate  since  it  follows  the  logical  con¬ 
nectivity  of  the  system  data  flow,  while  providing  a  means  for  SETS  to  acti¬ 
vate  the  required  branches  of  the  RNETs. 

One  of  the  ALPHAS  of  TLS  is  REDUN_DETERMI NATION .  It  embodies  the 
requirements  for  identifying  two  images  as  redundant  if  their  state  esti¬ 
mates  are  close  enough  (relative  to  their  uncertainties)  for  them  to  be 
considered  duplicate  detections  of  the  same  object.  The  real  processing  to 
implement  such  a  requirement  would  have  to  select  at  least  a  subset  of  all 
images  then  being  tracked  for  state  comparison,  then  to  determine  redundancy 
by  an  appropriate  algorithm.  For  a  functional  model,  it  is  sufficient  to 
define  the  USE  of  STATE  (a  multielement  vector  in  reality)  as  BETA  and  its 
TYPE  as  REAL.  Then  two  instances  of  IMAGE_IN_TRACK  would  be  redundant  if 
their  values  of  STATE  were  equal.  The  corresponding  SETS  activity  is 
implemented  by  having  the  DATA  returned  in  the  radar  message  selected  to 
give  the  required  probability  of  redundancy. 

The  BETA  for  REDUN_DETERMI NATION  is  given  in  Figure  3-14. 

It  scans  all  instances  cf  IMAGE  IN_TRACK  (the  ENTITY  TYPE)  to  find  any 
value  of  STATE  equal  to  that  of  the  instance  to  which  the  current  return 
is  related.  If  redundancy  is  found,  the  REDUNDANT  IMAGE  DATA  is  assigned 
TRUE;  otherwise,  it  is  FALSE. 

3.4.2  Local  Data 

In  developing  the  BETA  for  each  ALPHA,  the  requirements  engineer  also 
pins  down  attributes  about  the  DATA  flow.  As  already  noted,  he  will  define 
some  high-level  DATA  as  being  sufficient  for  functional  modeling,  and  will 
give  them  corresponding  attributes  of  TYPE  and  USE.  Similarly,  he  will 
specify  USE:BQTH  for  DATA  required  in  a  functional  model  at  the  same  level 
of  fidelity  as  in  an  analytic  model.  In  addition,  he  will  identify  some 
DATA  required  for  intercommunication  of  ALPHAS  on  a  single  R  NET  during  a 
single  transaction  (enablement)  of  that  net.  For  example,  the  STATE  of  the 
IMAGE  IN  TRACK  corresponding  to  the  current  return  must  be  compared  in 
REDUN  DETERMINATION  with  that  of  all  other  instances.  Therefore,  a  DATA 
element  may  be  defined  as  OUTPUT  FROM  ALPHA: UPDATE  STATE  which  is  the 
CURRENT  STATE.  That  definition  is  needed  since  the  current  instance  of 
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IMAGE  IN  TRACK  (with  which  a  value  of  STATE  is  associated)  changes  during 
execution  of  the  ALPHA: REDUN  DETERMINATION.  Therefore,  the  DATA:CURRENT_ 

STATE  is  declared,  and  given  LOCALITY : LOCAL ,  TYPE:REAL,  and  USE : BETA .  Since 
the  value  of  the  state  vector  is  also  an  output  for  recording,  and  since  a 
MESSAGE  uses  only  LOCAL  DATA,  the  element  may  be  the  same  as  the  one  which 
MAKES  the  MESSAGE :STATE  UPDATE  which  is  also  required  from  that  R_NET . 

RADX  procedures  as  discussed  in  3.3.5  are  of  continuing  use  in  analyzing 
the  correctness  of  the  DATA  definitions.  The  user  is  encouraged  to  develop 
his  own  procedures  which  are  meaningful  to  his  particular  project. 

3.5  TRACEABILITY 

Traceability  is  a  feature  of  the  specification  supporting  its 
management,  rather  than  one  required  for  its  technical  quality  per  se. 
Therefore,  the  requirements  for  traceability  are  developed  in  the  manage¬ 
ment  volume,  and  are  addressed  here  only  in  terms  of  their  mechanical 
entry. 

3.5.1  Originating  Requirements 

The  originating  requirements  for  a  software  specification  are  most 
commonly  contained  in  higher-level  specifications.  In  general  (depending 
on  management  decision)  each  identifiable  software  requirement  in  each 
higher-level  specification  will  be  called  out  as  an  0KIGINATING_REQUIREMENT 

in  the  ASSM.  The  DESCRIPTION  attributed  to  an  ORI GI NATI NG _ ^REQUIREMENT  may 

be  a  literal  excerpt  of  the  source,  or  may  be  an  interpretation,  again  at 
management  discretion.  Note  that  ORIGINATINGREQUIREMENTs  in  REVS  do  not 
trace  to  one  anotl  er;  thus,  the  lowest  level  of  requirements  to  which  a 
DECISION  or  specification  element  traces  should  be  entered  as  the  ORIGI¬ 
NATING  REQUIREMENT. 

3.5.2  References 

There  may  be  sources  of  information  which  define  specifics  of  the 
software  requirements,  but  which  are  not  specifications  in  themselves.  For 
example,  a  table  of  constants,  or  a  book  defining  a  standard  atmosphere 
model  may  be  referenced  in  the  source  specifications  or  applied  by  the 
requirements  engineer  in  developing  the  software  specification.  Such  a 
REFERENCE  is  also  recorded  in  the  ASSM,  since  it  EXPLAINS  some  feature  of 
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the  required  processing.  Note  that  a  REFERENCE  may  be  changed  during 
development  of  either  the  specification  or  the  software;  when  such  a 
change  occurs,  its  impact  on  the  specification  may  be  followed  through 
the  EXPLAINS  relationship. 

3.5.3  Decisions 

As  was  noted  in  3.1.5,  the  process  of  developing  the  DPS  requirements 
may  expose  system  issues  which  cannot  be  resolved  immediately  in  a  formal 
manner,  but  which  may  have  significant  impact  on  the  direction  of  further 
work.  Each  such  issue  is  recorded  in  the  ASSM  as  a  DECISION  which  TRACES 
FROM  the  ORIGINATING_REQUIREMENT(s)  eitner  directly  or  through  other 
DECISIONS.  As  each  issue  is  encountered  it  should  be  given  a  DECISION 
name,  and  entered  in  the  ASSM  with  at  least  its  key  attributes:  a  statement 
of  the  PROBLEM,  the  recognized  ALTERNATIVES,  ar.d  the  CHOICE  among  them  which 
was  made  to  allow  work  to  proceed.  When  the  CHOICE  is  reviewed  by  system 
engineering,  its  correctness  can  be  confirmed,  or  the  implications  of  re¬ 
vising  it  can  be  assessed  through  analysis  of  those  elements  which  TRACE 
FROM  the  DECISION.  Paragraph  3.1.5  gives  an  example  of  the  input  needed 
to  state  one  of  the  TLS  issues. 

3.5.4  Relating  to  Sources 

The  relationships  TRACES  and  EXPLAINS  have  been  defined  to  link 
requirements  to  their  sources.  Each  element  of  the  ASSM  should  be  TRACED 
TO  its  ORIGINATING_REQUIREMENT(s)  either  directly  or  through  DECISIONS 
which  may  be  TRACED  themselves.  In  general,  the  ORIGINATING_REQUIREMENTs 
may  be  entered  into  the  ASSM  before  their  traceability  is  developed  (i.e., 
before  any  of  the  elements  have  been  defined).  As  the  R_NETs  are  built  and 
as  the  other  elements  are  entered,  their  links  with  any  ORIGINATING_REQUIRE- 
MENT  may  be  recorded  through  the  TRACES  relationship.  Whenever  a  DERIVATION 
is  encountered,  it  should  be  entered  and  TRACED  TO  its  source. 

Chronologically,  it  is  likely  that  the  first  entries  made  into  the 
ASSM  will  be  the  ORIGINATING_REQUIREMENTs ;  some  REFERENCES  may  ulso  precede 
development  of  the  R_NETs.  As  elements  are  developed,  DECISIONS  and 
additional  REFERENCES  will  be  recorded,  and  at  least  some  TRACES  and 
EXPLAINS  relationships  will  be  provided.  Before  publicati)n  of  the  speci¬ 
fication,  management  may  require  element  audjt  to  confirm  some  level  of 
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completeness  of  tracing;  throughout  development  of  both  the  specification 
and  the  resulting  software,  the  linking  should  be  monitored  to  track,  in 
the  specification,  evolution  of  requirements.  Note  that  it  is  good  prac¬ 
tice  in  requirements  engineering  to  explore,  through  the  data  extractor, 
the  impact  of  any  projected  modifications  to  requirements.  Particularly 
at  the  terminal,  it  is  convenient  to  query  the  ASSM  to  the  effect:  What 
if  the  DECISION  (name'  is  modified?  It  would  be  accomplished  LISTING  ALL 
WITH  an  appropriate  HIERARCHY  tha'  TRACED  TO  that  decision,  then  examining 
the  attributes  of  each  element  that  was  so  related.  Judicious  engineering 
would  tnen  focus  on  the  requirements  with  the  least  impact  when  looking  at 
the  set  which  might  be  altered  to  reflect  a  change  in  the  software  environ¬ 
ment  (e.g.,  the  threat). 

3.6  INFORMATIVE  MATERIAL 

Sections  3.1  through  3.4  have  shown  the  development  of  the  technical 
content  of  the  ASSM  from  the  entry  of  the  kernel  through  recording  func¬ 
tional  models.  In  addition  to  such  mandatory  material,  there  is  a  family 
of  supportive  information  which  might  be  recorded  for  any  element.  Charac¬ 
teristic  of  that  family  is  the  DESCRIPTION,  an  attribute  which  allows  an 
English-language  text  to  be  entered  (other  languages  might  be  used  except 
for  restrictions  due  to  character  sets)  to  explain  the  intent  of  the 
element.  Note  that  informative  material  is  not  constraining  on  the  pro¬ 
cess  designer,  and  is  not,  in  fact,  a  requirement  subject  to  test;  it  is 
merely  supportive  of  communication  between  the  requirements  engineer  both 
his  peers  and  the  process  designer.  The  need  for  any  informative  attribute 
and  the  auditim  of  its  entry  are  options  for  project  management,  and  are 
discussed  in  the  management  volume, 

3.6.1  Description 

A  text  string  of  arbitrary  length  may  be  entered  to  describe  any 
element  of  the  ASSM  under  the  attribute  DESCRIPTION.  Even  where  the  element 
carries  a  self-explanatory  name,  or  where  it  has  another  attribute  formally 
specifying  it,  a  DESCRIPTION  is  usually  valuable.  For  example,  the  IMAGE_ID 
is  as  simple  a  concept  about  an  IMAGE  as  can  be  promoted.  Nevertheless,  it 
would  be  useful  to  describe  it  as  being  assigned  from  the  HO  ID  of  the  ini¬ 
tiation  message,  and  as  being  embodied  also  as  the  TARGET  ID  in  the  ENTITY 
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CLASS  PULSE.  The  linkage  among  the  elements  is  defined  in  the  BETAs  of 
appropriate  ALPHAS,  of  course,  and  the  DESCRIPTION  is  not  binding.  But 
following  all  of  the  references  to  that  DATA  item  to  find  the  meaningful 
assignments  is  tedious  at  best,  where  the  DESCRIPTION  is  easily  absorbed. 

3.6.2  Synonym 

A  synonym  may  be  declared  and  EQUATED  TO  any  other  element  for  the 
convenience  of  the  engineer.  Frequently,  the  SYNONYM  will  be  a  short  name 
for  a  frequently  referenced  item,  so  that  at  least  some  of  the  references 
are  simplified;  occasionally,  the  naming  conventions  imposed  by  the  language 
will  prompt  the  use  of  a  cryptic  element  name,  so  that  an  explanatory 
SYNONYM  is  desired.  The  relationship  ABBREVIATES  may  be  regarded  as  equiva¬ 
lent  to  EQUATES;  it  is  an  artifact  of  early  REVS  design. 

3.6.3  Authorship 

In  the  current  REVS,  there  is  an  attribute  ENTERED_BY  which  permits 
the  author  of  information  about  an  element  to  record  his  name  and  the  date 
of  entry.  If  required,  that  operation  could  be  automated,  so  that  the' 
attribute  would  become  a  log  of  changes  made,  with  the  entry  provided  by 
the  system  whenever  a  value  or  relationship  was  altered. 

3.6.4  Complementary  Relationships 

Each  RSL  relationship  defines  a  connection  between  two  elements; 
since  it  is  transistive,  it  has  a  complement  which  simply  reverses  the 
subject  and  object.  When  information  is  extracted  from  the  ASSM,  both 
directions  of  the  relationship  are  derived  from  a  single  link;  thus,  both 
the  relationship  and  its  complement  are  extracted,  and  redundant  but 
absolutely  consistent  information  is  obtained.  Since  consistency  is 
assured,  redundancy  is  constructive  in  informing  the  user  about  all 
relationships  on  an  element  under  examination. 

3.6.5  Structural  References 

In  the  structure  segment,  an  R_NET  makes  use  of  other  elements. 
Implicitly,  it  has  a  relationship  to  each  such  element  which  appears  on 
its  STRUCTURE;  that  relationship  is  termed  REFERS,  and  is  implicit  in  use 
of  the  data  extractor  (RADX)  of  REVS.  The  relationship  and  its  complement 


are  visible  to  the  user  in  the  RADX  output,  but  are  entered  automatically 
and  implicitly  through  STRUCTURE  declaration,  not  through  the  conventional 
explicit  declarations. 

3.7  ANALYTIC  MODELS 

In  order  to  support  analytic  simulation,  detailed  models  of  data 
transformations  must  be  provided  in  the  ASSM.  For  each  ALPHA,  that  model 
is  entered  as  its  GAMMA  attribute  in  the  form  of  a  PASCAL  procedure. 

In  general,  an  analytic  model  will  be  an  idealized  method  of  per¬ 
forming  the  operations  required  by  the  ALPHA.  Typically,  it  will  be  un¬ 
realizable  in  a  real-time  system  due  to  its  size  or  complexity.  Since  the 
requirements  statement  is  independent  of  the  machine  on  which  its  implemen¬ 
tation  is  to  execute,  real-time  constraints  do  not  apply,  and  the  idealized 
algorithm  is  suitable  for  the  existence  proof  that  the  analytic  simulation 
is  to  provide. 

Another  useful  way  of  looking  at  an  analytic  model  is  to  begin  with  a 
TEST  of  a  PERFORMANCEREQUIREMENT.  In  general,  such  a  TEST  will  be  a  func¬ 
tion  of  the  outputs  of  processing  (MESSAGES  and  DATA  entered  into  the  global 
data  base)  relative  to  DPS  inputs  (MESSAGES).  In  a  mathematical  sense,  the 
TEST  might  be  inverted  to  provide  an  algorithm  for  converting  the  inputs  to 
the  required  outputs.  If  that  inversion  is  partitioned  into  the  ALPHAS  along 
the  processing  path,  it  might  become  the  set  of  GAMMAs  needed  at  this  stage. 

For  example,  if  the  requirement  is  that  a  specific  differential 
equation  is  to  be  satisfied,  the  equation  itself  serves  as  the  TEST  (see 
Section  4),  while  the  GAMMAs  for  the  appropriate  ALPHAS  provide  one  means 
of  solving  the  equations.  If  we  did  not  require  that  a  set  of  GAMMAs  be 
generated  and  validated,  we  could  not  confirm  the  correctness  of  the  speci¬ 
fication.  Thus,  it  is  simple  to  specify  a  perpetual -motion  machine  (the 
power  available  at  the  output  port  equals  or  exceeds  that  supplied  at  all 
input  ports),  but  very  difficult  to  provide  a  proof  of  one's  existence. 

The  GAMMAs  may,  in  principle,  be  generated  in  exactly  the  same  way 
as  the  BETAs.  In  practice,  only  the  simplest  will  be  treated  in  so  light 
a  manner;  the  majority  of  the  ALPHAS  will  require  modelling  by  a  team  of 
experts  in  the  particular  disciplines  required  for  that  processing.  For 
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example,  the  ALPHA: UPDATE  STATE  h Sc  a  „ 

would  probably  be  a  hlgh-order  Kalraa,  fm*  S1r"P  BETA  m0deK  ltS  GAHMA 
ment.  Time  and  cost  iLt  ♦  be, u, ring  months  of  develop- 

any  ALPHAS  of  TLS  ^  P“  •'  GAMMA,  for 


mm 


4.0  PERFORMANCE  REQUIREMENTS 


Performance  requirements  specify  how  well  the  functional  requirements 
must  be  implemented  within  the  real-time  process.  While  the  set  of  func¬ 
tional  requirements  specifies  the  meaning  and  integrity  of  data  to  be  out¬ 
put  by  the  process,  each  performance  requirement  constrains  one  or  more 
mathematical  expressions  over  a  collection  of  these  outputs  and  internal 
data.  In  general,  the  system  specification  will  establish  performance 
criteria  at  a  level  higher  than  that  of  the  functional  criteria;  consequently 
the  methodology  provides  for  performance  requirements  to  be  specified  as 
constraints  on  a  collection  of  data  Produced  from  a  series  or  combination 
of  functional  requirements,  thereby  indirectly  constraining  each  embodied 
functional  requirement.  This  provision  within  the  methodology  does  not 
preclude  the  requirements  engineer  from  decomposing  the  system  specification 
performance  criteria  into  component  performance  requirements  for  allocation 
to  separate  elements;  however,  it  does  support  flexibility  to  enhance 
design  freedom  for  the  process  designer. 

An  example  of  a  simple  performance  requirement  might  be  a  specified 
accuracy  of  an  output  relative  to  a  defined  precision  of  the  input  from 
which  the  output  is  determined.  Similarly,  in  a  real-time  process  it  is 
often  necessary  to  constrain  the  interval  of  time  between  arrival  of  a 
stimulus  at  an  input  port  and  the  appearance  of  a  response  at  an  output 
port.  Most  often,  a  performance  requirement  establishes  the  criteria  for 
a  mathematical  expression  which  must  be  satisfied  when  applied  to  the  data 
in  the  process,  and^frequently  applies  over  the  course  of  an  engagement 
rather  than  at  any  single  point  in  time.  Consequently,  performance  require¬ 
ments  in  a  system  specification  tend  to  be  global  in  nature  and  are  defined 
at  the  subsystem  level. 

Historically,  performance  requirements  have  been  stated  in  the  English 
language  and,  as  a  consequence,  were  subject  to  interpretation.  Frequently, 
the*se  interpretations  were  not  unique  and  the  meaning  and  understanding 
achieved  by  the  developer  did  not  coincide  with  that  intended  by  the  specifier. 
As  an  example,  in  the  track  loop  problem  the  specification  established  a 
constraint  on  the  total  energy  to  be  allocated  to  an  image.  Within  the 
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Track  Loop  System  construct,  there  exist  three  possible  applications  of 
this  performance  requirement  depending  on  the  particular  interpretation  of 
the  developer:  if  (1)  the  requirement  is  applied  at  the  output  of  the 
allocator,  allowance  for  scheduling  conflicts  or  for  radar  subsystem 
performance  is  not  included;  if  (2)  the  requirement  is  applied  at  the  out¬ 
put  to  the  radar  subsystem,  provisions  for  scheduling  conflicts  would  be 
included;  however,  if  (3)  the  requirement  is  applied  at  the  point  where 
radar  returns  are  input  and  processed,  then  scheduling  conflicts  and  radar 
preemptions  are  accounted  for  and,  in  addition,  the  non-DPS  term  which 
correspond;  to  radar  processing  between  transmission  of  the  signal  arid 
receipt  of  the  return  at  the  processor  interface  is  also  included. 

In  an  effort  to  eliminate  ambiguities  in  the  statement  of  performance 
requirements  to  the  process  designer,  SREM  employs  a  machine-readable 
language  (RSL)  with  clearly  defined  elements,  structures,  relationships 
and  attributes.  With  RSL,  the  requirements  engineer  can  specifically  and 
discretely  specify  performance  requirements  to  the  process  designer. 

Within  the  validation  segment  of  REVS,  the  requirements  engineer  states 
the  performance  constraint  as  a  procedure  which  operates  on  data  collected 
at  specified  points,  VALIDATION_POINTS,  along  the  R_NET  STRUCTURE.  For 
each  constraint  an  unambiguous  pass/fail  decision  is  determined  for  the 
explicit  TEST  which  the  requirements  engineer  formulates  and  asserts  is 
sufficient  to  declare  that  the  PERFORMANCE_REQUIREMENT  is  satisfied. 

In  the  track  loop  example  mentioned  above,  where  the  test  to  assure 
satisfaction  of  the  performance  constraint  is  applied  at  the  output  to  the 
radar  subsystem,  the  collection  of  data  to  be  operated  on  by  the  test 
procedure  includes  those  data  which  make  the  outgoing  radar  message  and 
the  remembered  copy  of  the  data  from  which  the  outgoing  message  was  formed 
and  which  is  ASSOCIATED  WITH  the  ENTITY_CLAS$  PULSE.  By  locating  the 
point  for  data  measurement  (VALIDATION_POINT)  at  the  output  to  the  radar 
subsystem,  the  specific  DATA  and  FILES  required  by  the  test  procedure  are 
accessed  and  retrieved  such  that  the  particular  test  can  be  exercised, 
thereby  eliminating  ambiguity  in  the  performance  requirement  statement. 
Inclusion  of  the  VALIDATION_PATH  descriptors  for  connectivity  and  trace- 
ability  to  the  ORIGINATING_RCQUIREMENT  and  any  DECISIONS  involved  in 


interpretations  of  the  performance  constraint  completes  the  definition 
and  clarifies  the  requirement. 

Determination  of  consistency  between  the  derived  performance  require¬ 
ments  and  the  performance  specifications  depends  heavily  on  simulation  as 
does  determination  of  consistency  between  the  functional  requirements  and 
the  functional  specifications.  Performance  requirements  include  two  ranges 
of  constraints  -  those  local  to  the  process  and  those  of  a  global  nature 
which  apply  to  the  system  as  a  whole;  functional  requirements  are  local  to 
the  process.  Performance  requirements,  taken  as  a  whole,  can  be  said  to 
be  consistent  (both  with  one  another  and  with  the  laws  of  nature)  when 
there  is  an  existence  proof  of  a  simultaneous  solution  to  both  the  local 
and  global  requirements.  Therefore,  to  demonstrate  that  the  performance 
specification  and  the  derived  performance  requirements  are  achievable  in 
some  process,  it  is  sufficient  to  find  a  set  of  algorithms  which,  when 
executed  as  specified  by  the  R_NET  STRUCTURE  and  the  data  connectivity, 
satisfies  the  collection  of  performance  requirements.  The  candidate 
algorithms  mechanized  for  this  execution  are  written  as  PASCAL  procedures 
and  are  attributed  to  the  ALPHAS  which  each  analytically  models.  These 
PASCAL  procedures  (GAMMA  models)  are  linked  together  by  the  REVS  simulation 
generation  process  to  form  an  analytical  simulator  in  exactly  the  same  sense 
that  the  functional  models  (BETA  models)  are  linked  to  form  a  functional 
simulator.  To  the  user,  the  principal  difference  between  the  functional 
and  performance  requirements  simulators  is  that  the  performance  results 
from  analytic  simulation  are  assessed  against  the  requirements  defined  in 
each  PERFORMANCE_REQUIREMENT  TEST  to  determine  sufficiency  of  the  solution. 

The  precision  of  the  methodology  developed  for  specifying  functional 
requirements  is  not  readily  available  in  specifying  performance  requirements 
due  primarily  to  the  local  and  global  range  inherent  in  the  performance 
specification.  That  is,  although  the  capabilities  within  the  methodology 
provide  for  an  explicit  and  precise  statement  of  each  performance  require¬ 
ment,  translation  from  the  English  representation  of  the  specifications  in 
the  source  material  to  the  particular  PF.RFORMANCE_REQUIREMLNT  depends 
heavily  on  the  judgement  of  the  requirements  engineer  and  consequently  can 
be  treated  as  "methodical"  only  in  a  limited  sense.  Therefore,  the  following 
sections,  describing  the  approach  to  developing  performance  requirements, 
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will  tend  to  be  more  illustrative  than  derinitive  and  represent  the  thought 
process  to  be  conducted  by  the  requirements  engineer  rather  than  specific 
rules  to  be  followed. 


The  following  steps  outline  the  guidelines  developed  in  subsequent 

sections  to  specify  performance  requirements. 

Step  1.  The  system  specification  is  analyzed  and  each  performance 

requirement  is  identified,  named  and  entered  into  the  ASSM  data 
base.  This  activity  is  continued  until  all  PERFORMANCE  REQUIRE¬ 
MENTS  have  been  inserted  along  with  the  ORIGINATING  REQUIREMENT 
or  DECISION  that  each  PERFORMANCE_REQUIREMENT  is  TRfiCEDJROM. 

Step  2.  Each  PERFORMANCE_REQUIREMENT  is  considered  in  conjunction  with 
the  R_NET  or  SUBNET  STRUCTURES  to  identify  the  point  along  the 
net  at  which  the  test  for  satisfaction  of  the  requirement  most 
appropriately  applies.  This  point  establishes  the  location  of  the 
VALIDATION-POINT  that  determines  the  termination  of  the  VALIDATION_ 
PATH  that  is  to  be  CONSTRAINED  BY  the  PERFORMANCEJEQUIREMENT. 

(It  should  be  noted  that  in  certain  cases  a  single  VALIDATION_POINT 
may  be  all  that  is  required  to  implement  a  TEST  of  the  PERFORMANCE_ 
REQUIREMENT.)  This  activity  is  continued  until  a  point  of 
application  for  the  TEST  for  each  PERFORMANCE_REQUIREMENT  has  been 
located  along  the  R_NET  or  SUBNET  STRUCTURES  and  a  VALIDATION  JOINT 
has  been  named  and  entered  into  the  ASSM  data  base  as  an  element- 
type  and  located  on  the  STRUCTURE. 

Step  3.  An  initial  TEST  which  satisfies  each  PERFORMANCE  REQUIREMENT  is 

formulated  and  analyzed  based  on  data  at  the  VALTDATI0N_P0INT.  In 
general,  analysis  of  the  initial  TEST  formulation  will  result  in 
the  determination  that  additional  data,  not  available  at  the  single 
VALIDATION_POINT,  will  be  required  to  support  the  TEST.  Consequently, 
additional  VALIDATION_POINTs  are  identified,  named  and  appropriately 
located  on  the  R__NET  and  SUBNET  STRUCTURES  within  the  ASSM.  This 
activity  Is  continued  until  the  necessary  VALIDATION_POINTs  have 
been  defined  such  that  the  collection  of  data  required  for  each 
TEST  has  been  made  available  from  the  DATA  and  FILEs  accessible 
on  the  nets.  At  this  time,  DATA  and  FILES  required  from  each 
VALIDATION_POINT  are  declared  to  be  INPUT  TO  the  respective 
VALIDATION JOINT  and  entered  into  the  ASSM.  The  VALIDATION^ 

POINTS  are  then  considered  collectively  and  VALIDATION_PATHs 
are  then  named. 

Step  4.  An  initial  PATH  structure  for  each  VALIDATION_PATH  is  entered  Into 
the  ASSM  considering  the  VALIDATION_POINTs  and  EVENTS  required 
for  each  initial  TEST  formulation.  This  activity  is  continued 
until  a  PATH  structure  has  been  declared  for  each  VALIDATION  PATH 
constrained  by  each  PERFORMANCE  REQUIREMENT. 
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Step  5. 


The  requirements  engineer  is  now  in  a  position  to  finalize  each 
TEST  formulation  and  refine  the  initial  declaration  of  VALIDATION_ 
POINTS  and  VALIDATION_PATHs  for  each  PERFORMANCE_REQUIREMENT  TEST. 
Each  TEST  is  coded  as  a  PASCAL  procedure  and  entered  into  the  ASSM 
as  an  attribute  of  the  respective  PERFORMANCE_REQUIREMENT. 

Step  6.  The  requirements  engineer  now  identifies  the  port-to-port  response 
times  required  by  the  system  specification.  For  each  performance 
specification  a  PERFORMANCE_REQUIREMENT  TEST  is  defined  including 
the  attendant  VALIDATION_POINTs  and  their  RECORDS  relationships, 
and  the  constrained  VALIDATION_PATH  with  PATH  structure  and  with 
MAXIMUM_TIME,  MINIMUMJIME  and  UNITS  attributes  in  the  same  manner 
that  other  PERFORMANCE_REQUIREMENT  statements  are  developed.  These 
descriptors  are  entered  into  the  ASSM  to  complete  the  initial 
definition  of  the  performance  requirements  statement. 

At  this  point  the  requirements  engineer  has  completed  the  initial 
activities  of  SREM  necessary  to  explicitly  and  unambiguously  state 
PERFORMANCE_REQUIREMENTs.  The  remaining  activities  Involve  confirmation 
that  the  statements  are  consistent  and  complete.  These  activities  employ 
the  static  arnd  dynamic  checking  features  of  REVS  and  the  execution  of 
the  analytical  simulation  built  by  REVS. 

4.1  LOCATE  TEST  POINTS 

A  PERFORMANCE  REQUIREMENT  is  stated  relative  to  data  collected  at 
specific  VALIDATION_POINTs  located  on  the  R_NET  and  SUBNET  STRUCTURES.  Even 
in  simple  cases,  identification  of  the  data-col lection  points  is  critical 
to  the  interpretation  of  a  system  performance  constraint.  The  content  and 
context  of  the  specification  in  the  source  material  is  used  by  the  require¬ 
ments  engineer  to  determine  the  system  engineer's  intent  and  from  which 
the  test  point  is  defined. 

As  an  example,  consider  the  specification  statement  in  the  TLS  DPSPR 
(Appendix  F)  which  requires  that  "The  DPS  shall  allocate  radar  commands 

so  that  not  more  than  (TBD)  joules  are  commanded  per  image . "  At 

least  three  interpretations  can  be  associated  with  this  apparently  explicit 
requirement. 

1)  The  allocator  shall  assign  track  rates  such  that  the 
accumulated  sum  of  the  energy  for  each  image  over  the 
engagement  (the  product  of  the  allocated  pulse  rate,  the 
energy  per  pulse  and  the  duration  of  the  allocation)  shall 
not  exceed  the  specified  limits; 
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2)  The  energy  required  by  the  radar  commands  transmitted  across 
the  interface  to  the  radar  shall  not  exceed  the  specified 
limit;  or 

3)  The  energy  required  by  the  radar  commands  acted  upon  by 
the  radar,  as  detected  by  the  DPS  in  the  radar  return 
messages,  shall  not  exceed  the  specified  limit. 

Since  not  all  of  the  pulses  allocated  per  image  may  be  scheduled  and 
since  some  of  the  scheduled  pulses  may  be  pre-empted  by  the  radar,  the 
three  interpretations  lead  to  different  performance  requirement  definitions. 
The  first  point  in  the  methodology  at  which  the  interpretation  becomes 
important  is  during  the  process  of  locating  the  VAL IDATION  POINT  on  the 
R_NET  or  SUBNET  at  which  the  TEST  for  compliance  with  the  system  specification 
is  to  be  made.  For  the  first  interpretation,  the  test  point  should  be 
located  at  the  output  of  the  allocator;  for  the  second  interpretation, 
the  test  point  should  be  located  at  the  input  to  the  OUTPUT_INTERFACE  RADAR_ 
OUT;  for  the  third  interpretation,  the  test  point  should  be  located  at  the 
output  of  the  INPUT_INTERFACE  RADARIN.  In  the  Track  Loop  example, 
development  of  the  PERFORM 'NCE_REQU I REMENT  was  based  on  the  second  interpre¬ 
tation  and  is  TRACED  FROM  a  DECISION  which  delineated  the  development 
process,  through  use  of  the  DECISION  attributes,  the  PROBLEM,  the  ALTERNATIVES 
and  the  CHOICE. 

The  VALIDATION_PGINT  at  which  the  final  data  is  collected  on  which 
the  PERFORMANCE_REQU I REMENT  TEST  operates  in  most  cases  is  associated  with 
the  point  in  processing  along  the  path  at  which  the  test  is  relevant.  In 
general,  selection  of  the  appropriate  R_NET  or  SUBNET  is  critical  to  the 
requirements  definition;  however,  the  particular  location  along  the  net 
may  offer  some  flexibility  depending  on  the  type  of  data  involved.  Since, 
in  REVS,  execution  of  a  net  occurs  in  zero  time,  the  selected  location  may 
be  any  point  at  which  the  required  data  are  available.  As  an  example, 
the  energy  per  image  constraint  defined  by  the  third  interpretation  could 
be  applied  at  a  point  on  the  RESPONSE_TO_RADAR  R_NET  either  preceding  or 
following  the  ALPHA:  ACCEPT_AND_CHECK_RADAR_RETURN_MESSAGE. 

At  th’s  point  in  the  methodology,  the  ASSM  should  contain  the  following 
performance  related  RSL  statements,  described  in  the  order  in  which  they 
would  generally  be  entered. 


1)  Each  OR I G I  NAT I NG_REQU I REMENT  will  have  been  defined. 

2)  Each  PERFORMANCE  REQUIREMENT  will  have  been  identified 
including  traceability  to  the  ORIGI NATING_REQU I REMENT . 

3)  Each  DECISION  involved  in  deriving  each  PERFORMANCEREQUIREMENT 
based  on  interpretation  of  the  ORIGINAT I NG  REQUIREMENT  will 
have  been  defined.  Explicit  declaration  of  the  DECISION 
attributes  PROBLEM,  ALTERNATIVES  and  CHOICE  will  be  included. 

4)  The  VALIDATION  POINT  at  which  each  PERFORMANCE_REQU I REMENT 
TEST  is  to  be  applied  will  have  been  identified  and  uniquely 
named. 

5)  The  appropriate  R-NET  and  SUBNET  STRUCTURES  will  have  been 
updated  to  include  the  location  of  each  VALIDATION_POINT 
node. 

The  RSL  statements  and  R_NET  STRUCTURE  are  provided  in  Figure  4-1  for 
the  energy-per-image  constraint. 

4.2  DEFINE  DATA  AND  TESTS 

A  VALIDATION_POINT  is  precisely  a  port  through  which  simple  DATA  are 
accessed  and  through  which  DATA  and  FILEs  ASSOCIATED  WITH  ENTITY_CLASSes 
and  ENTITY_TYPEs  are  extracted,  all  of  which  is  RECORDed  for  post-processing 
by  the  PERFORMANCE_REQU I REMENT  TEST  in  the  REVS  validation  segment.  These 
DATA  are  obtained  during  simulation  from  the  global  data  base  defined  by 
the  functional  requirements  specifications.  Simple  DATA  (not  in  an  entity, 
file,  or  message  hierarchy)  which  must  be  recorded  at  a  VALIDATION_POINT 
are  related  to  that  point  via  RECORDS.  Message  DATA  are  similarly  RECORDED 
BY  a  named  VALIDATION_POINT  on  the  R_NET  to  which  they  are  LOCAL.  If  an 
entire  FILE  is  to  be  recorded,  the  relationship  RECORDS  may  be  applied  to 
it  as  well. 

For  DATA  which  are  CONTAINED  IN  a  FILE,  or  are  ASSOCIATED  WITH  an 
ENTITYjCLASS  or  ENTITY_TYPE,  a  problem  may  arise  in  defining  the  instance 
of  the  repeated  data  for  which  the  DATA  are  to  be  RECORDED.  In  general, 
the  instance  desired  will  have  been  selected  earlier  on  the  R_NET.  For 
example,  the  PULSE  which  is  relevant  for  the  PERFORMANCE_REQUI REMENT: 
ENERGY_PER_IMAGE  is  the  one  which  was  CREATED  BY  the  ALPHA:  PICKROMMAND. 
Since  no  intervening  activity  could  modify  the  selection,  the  DATA  corre¬ 
sponding  to  that  PULSE  are  available  to  the  VALIDATION_POINT  used  for  the 
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ORIGINATING.RFQUIREMENT:  PADAR.RESOHRCE.CONTROL.R . 

DESCRIPTION: 

f  DPSPP  PARAGRAPH  3.2.4(B) »  RESOURCE  CONTROL ♦  STATES  THAT 
(••THE  DPS  SHALL  ALLOCATE  RADAR  COMMANDS  SO  THAT  NOT  MORE 
THAN  (TBD)  JOULES  ARE  COMMANDED  PFR  IMAGE ♦  NOR  MOPE  THAN 
( TRO)  KILOWATTS  OR  ( TPD)  PULSES /SECOND  FOR  ALL  IMAGES  IN 
TRACK.") I . 

PFRF0RMANCE_RFQUIREMFNT:  CNERGY.PER.IMAGE. 

TPACEO  from:  ORIGINATING_REQUIREMRNT :  RADAP_RESOURCE_CONTROL_B. 

PERF0RMANCE_PFQUIREMENT :  PULSES_PER„SECOND. 

TRACED  from:  ORIGINATING_REQUIREMENT:  RADAR_RESOUPCE_CONTROL_B. 

PERFORMANCE.PFOUTREMFNT :  RADIATFD.POWFR. 

TRACED  FROM:  OPIGINATING.PEQUIPEMFNT  :  R AD AR_  RESOURCE .CONTROL..B  • 

DECISION:  RADAR_RESOUPCF_CONTROL_Bl . 

PROBLEM: 

fDPSPR  PARAGRAPH  3.2.4(B)*  STATEMENT  ("THE  DPS  SHALL 
ALLOCATE  RADAR  COMMANDS  SO  THAT  NOT  MORE  THAN  ( T8D)  JOULES 
ARE  COMMAMDEO  PER  IMAGE*...")  ALLOWS  FOR  THREE  POSSIBLE 
INTERPRETATIONS  IN  DETERMINING  THE  POINT  AT  WHICH  THE 
PERFOPMANCE.REOUIREMENT  TEST  IS  APPLIED.!. 

ALTERNATIVES: 

[1.  THE  ALLOCATOR  SHALL  ASSIGN  TRACK  PATES  SUCH  THAT  THE 
CUMULATIVE  SUM  OF  THE  ENERGY  FOP  EACH  IMAGE  OVER  THE 
ENGAGEMENT  (THE  PRODUCT  OF  ALLOCATED  PULSE  RATE* 

ENERGY  PER  PULSE*  AND  DUPATION  OF  ALLOCATION)  SHALL 
NOT  FXCEED  (TRO)  JOULES. 

?.  THE  ENERGY  REQUIRED  BY  THF  RADAR  COMMANDS  TRANSMITTED 
ACROSS  THE  INTERFACE  TO  THF  RADAR  SHALL  NOT  EXCEED 
(TRO)  JOULES. 

3.  THE  FNERGY  REQUIRED  BY  THE  RADAR  COMMANDS  ACTED  UPON 
BY  THF  RADAR  AS  DETECTED  BY  THE  DPS  IN  THE  RETURN 
MESSAGES,  SHALL  NOT  EXCEED  (TBD)  J0ULF5.I. 

CHOICF: 

TP.  THE  FNERGY  PFOUIREO  BY  THE  RADAR  COMMANDS  TRANSMITTED 
ACROSS  THE  INTERFACE  TO  THE  RADAR  5HALL  NOT  EXCEED 
(TBD)  JOULES  SHALL  BE  TESTED  FOR  COMPLIANCE  AT  THE 
INPUT  TO  THF  OUTPUT  INTERFACE:  RADAR.OUT.t. 

TRACED  FROM:  OPIGlNATING_REQUIREMFNT:  RADAR_RFSOUPCE_CONTROL«B. 

TRACES  TO:  PERFORMANCE.PEOUIREMENT :  ENERGY.PER.IMAGE, 

VAL I DA  T I ON_POI NT :  RADAR_COMMAND.OUTPUT.POI  NT . 

TRACED  FROM:  OFCISION:  P AD AR_RE SOURCE. CONTROL _B 1 • 


Figure  4-1  Performance  Requirements  Statements  Representation 
at  the  Completion  of  SREM  Step  -  Locate  Test  Points 
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requirement.  However,  the  energy  of  that  command,  which  is  also  needed 
for  the  TEST,  is  not  so  simply  available. 

The  energy  of  the  pulse  is  a  part  of  the  WF_CHARACTERISTICS  in  the 
FIlE:  WAVEFORM  TABLE.  The  link  between  the  PULSE  and  the  WAVEFQRM_TABLE 
is  the  identifier  of  the  kind  of  transmission,  the  PULSt_TYPE  and  WF_NAME, 
respectively.  (Similarly,  the  waveform  identifier  is  the  RADAR_TYPE  of  the 
outgoing  command  MESSAGE.)  There  are  three  obvious  ways  of  obtaining  the 
required  information. 

1)  RECORD  either  the  PULSE  TYPE  or  the  RADAR JTYPE  from  XMIT_R; 
RECORD  the  WAVEFORM_TABLE  once  (say  after  ALPHA:  STARTER, 
where  it  was  created);  co-relate  the  information  in  the  TEST. 

2)  Provide  an  ALPHA  with  ARTIFICIALITY:  VALIDATION  before  the 
VALIDATION_POINT  to  select  the  WFJAME;  assign  the  WFjCHARAC- 
TERISTICS  in  that  ALPHA  to  a  new  LOCAL  DATA  item;  and  RECORD 
that  DATA  item. 

3)  Provide  a  GLOBAL  DATA  item  at  some  earlier  processing  point 
with  ARTIFICIALITY:  VALIDATION  and  pass  it  along  appropriately 
to  the  VALIDATIONS  I  NT  where  it  is  to  be  RECORDED. 

In  TLS ,  the  third  choice  is  attractive  because  there  is  a  DATA  item  left 
from  early  thinking  on  the  problem  which  has  the  required  properties.  The 
DATA:  COMMAND  ENERGY  was  once  thought  to  be  useful  on  R_NET:  XMIT_R.  Con¬ 
sequently,  it  was  included  in  each  record  of  the  FILE:  COMMAND.  But  develop¬ 
ment  of  the  models  made  it  clear  that  the  element  was  not  needed  for  XMIT_R, 
so  it  might  be  deleted.  However,  it  has  exactly  the  right  properties  for 
an  ARTIFICIAL  element,  since  its  value  is  the  energy  of  the  COMMAND  which 
would  be  selected  by  PICK_COMMAND  for  this  transmission. 

The  choice  among  the  options  available  is  up  to  the  requirements 
engineer,  and  the  process  designer  should  recognize  that  there  are  degrees 
of  freedom  in  the  selection  which  can  be  reexamined  if  the  design  would 
benefit.  For  TLS,  the  first  option  is  particularly  attractive:  the  FILE 
to  be  recorded  contains  only  constants,  so  that  correlation  of  data  in  the 
TEST  poses  no  problem.  The  third  option  may  also  be  acceptable,  since  it 
ensures  that  the  DATA  RECORDED  for  the  PERFORMANCE_REQUIREMENT  are  clearly 
those  which  are  needed.  The  second  option,  which  modifies  the  R_NET  with 
an  ARTIFICIAL  element  is  esthetically  less  desirable  than  either  of  the 
other  choices.  For  the  purposes  of  this  document,  the  first  option  is 
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selected,  and  an  additional  VALIDATION _ ^POINT :  STARTING_POINT  is  identified 

immediately  following  the  ALPHA:  STARTER  to  RECORD  the  FILE:  WAVEFORM_TABLE. 

A  TEST  is  a  PASCAL  procedure  attributed  to  a  PERFORMANCE_REQUIREMENT 
which  CONSTRAINS  one  or  more  VALIDATION_PATHs.  The  TEST  executes,  in  a 
post-processing  environment,  on  those  DATA  which  have  been  RECORDED  BY  one 
or  more  VALIDATION_POINTs  required  to  collect  the  DATA  to  be  tested  and 
which  appear  as  nodes  on  the  PATH  structure  of  a  VALIDATION_PATH  that  is 
CONSTRAINED  BY  the  PERFORMANCE_REQUIREMENT.  Recall  that  data  required  for 
the  TEST  are  RECORDed  on  an  output  data  set  by  means  of  the  VALIDATION^ 

POINT  relationships  and  attributes  and  each  data  record  is  labeled  in  the 
output  data  set  by  the  VALIDAVIONPOINi  name.  During  post-process  TEST 
execution,  the  TEST  must  access  the  appropriate  data  record  in  the  output 
data  set  and  does  so  with  use  of  the  RETRIEVE  operator. 

The  requirements  engineer  may  choose  to  define  the  VALIDATION_PATHs, 
the  PERFORMANCE_REQUIREMENTs  and  the  TESTs  concurrently;  however,  in  doing 
so  he  minimizes  the  effectiveness  of  REVS  capabilities  which  support  E hi s 
activity  through  static  checking  of  the  RSL  statements.  It  is  recognized 
that  the  requirements  engineer  must  have  a  concept  of  the  TEST  configuration 
at  the  time  the  VALIDATION  POINTS  and  VALIDATION_PATHs  are  defined.  Keep 
in  mind,  however,  that  it  is  mandatory  that  the  TEST  be  configured  based  on 
the  data  available  on  the  RNET  and  SUBNET  STRUCTURES.  It  is  only  after 
all  attempts  have  failed  to  produce  a  valid  TEST  configuration,  under  these 
constraints,  that  the  requirements  engineer  should  redefine  the  R_NET  and 
SUBNET  STRUCTURES  or  introduce  STRUCTURES  and  element  types  with  attribute 
ARTIFICIALITY  in  order  to  accomplish  the  TEST  definition.  Consequently, 
it  is  recommended  that  the  requirements  engineer  approach  the  PERFORMANCE_ 
REQUIREMENTS  definition  in  a  top-down,  step-wise  manner.  That  is, 

1)  Examine  each  PERFGRMANCE_REQUIREMENT  to  determine  the  functional 
requirement,  defined  by  the  R_NET  and  SUBNET  STRUCTURES,  to 
which  the  PERF ORMANCE_REQU I REMENT  applies. 

2)  Examine  the  DATA  available  along  the  RNET  and  SUBNET  STRUCTURES 
to  a)  determine  a  point  of  optimal  location  (the  terminal 
VALIDATION_POINT)  at  which  a  TEST  should  be  performed  and  b) 
provide  insight  into  formulation  of  the  TEST. 

3)  Declare  the  necessary  DATA  and  FILEs  at  this  point  as  RECORDED 
BY  the  terminal  VALIDATION  POINT  and  formulate  the  initial 
TEST. 
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4)  Define  and  locate  additional  VALIDATION  POINTS  based  on 
data  requirements  for  the  TEST  formulation  and  declare  the 
necessary  DATA  and  FILEs  as  RECORDED  BY  these  additional 
VALIDATION  POINTS. 

5)  Define  and  locate  the  initial  VALIDATION  POINT,  that  is,  the 
earliest  occurring  VALIDATION_POINT  appearing  along  the  R_NET 
and  SUBNET  processing  flow  that  defines  the  functional  require¬ 
ment  to  which  the  PERFORMANCE_REQUIREMENT  applies. 

6)  Name  the  VALIDATION_PATHs  of  the  nets. 

7)  Relate  the  VALIDATION  PATHs  to  the  PERFORMANCE  REQUIREMENT 
which  CONSTRAINS  them. 

Application  of  these  steps  to  the  definition  of  PERFORMANCE_REQUIRE- 
MENT  statements  yields  an  orderly  development  process  and  provides  maximum 
utility  of  the  features  provided  in  the  REVS  RADX  and  VALIDATION  segments. 
Exceptions  to  this  step-wise  development  process  may  occur  when  a  single 
PERFORMANCE  REQUIREMENT  applies  to  more  than  one  functional  requirement 
defined  by  R_NETs  and  SUBNETS  that  are  not  connected  by  EVENT  enablements. 

Under  these  circumstances,  the  general  solution  is  effected  by  allowing  the 
PERFORMANCE_REQUIREMENT  to  constrain  multiple  VALIDATION_PATHs .  Alternatively, 
the  requirements  engineer  may  choose  to  decompose  the  single  PERFORMANCE_ 
REQUIREMENT  into  multiple  requirements  which  apply  explicitly  to  the  func¬ 
tional  requirements  defined  by  each  non-connective  R_NET  and  SUBNET  STRUCTURE. 

In  mechanically  applying  the  step-wise  process,  the  requirements 
engineer  would  read  the  system  specification  and  enumerate  the  statements 
of  performance  as  ORIGINATING_REQUIREMENTs .  Each  requirement  is  then 
located  on  the  R  NETs  and  SUBNETS  as  one  or  more  V.UIDATION_POINTs .  Each 
PERFORMANCEREQUIREMENT  and  VAL I DAT I ON  PATH  is  then  named.  A  PERFORMANCE_ 
REQUIREMENT  is  logically  named  for  its  content,  such  as  ENERGY_PER_IMAGE 
which  is  used  for  the  track  loop  example  discussed  previously.  Similarly, 
where  the  second  interpretation  of  the  ORIGINATING_REQUIREMENT  was  implemented, 
the  VALIDATION  PATH  is  named  RADAR  JCOMMANDJDUTPUT  which  signifies  both 
the  location  of  the  test  and  the  data  to  which  the  test  applies.  In  this 
particular  case  the  PERFORMANCE_REQUIREMENT  CONSTRAINS  a  degenerate 
VALIDATION  PATH  (i.e.,  only  one  VALIDATION_POINT  is  required);  consequently, 
the  VALIDATION  PATH  declaration  serves  only  to  establish  continuity  within 
the  RSL  statements.  The  single  VALIDATION_POINT  is  appropriately  named 
RADAR  COMMAND  OUTPUT  POINT. 
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The  requirements  engineer  next  considers  each  requirement  in  the 
specification  separately,  and  identifies  for  each  VALIDATION  POINT  the 
information  which  must  be  extracted  to  support  the  TEST  for  compliance. 

Note  that  a  single  VALIDATION  POINT  may  be  used  to  collect  data  for  multiple 
PERFORMANCE  REQUIREMENTS;  consequently,  it  may  appear  in  the  PATH  structures 
of  several  VALIDATION  PATHS.  Therefore,  the  DATA  and  FILES  declared  as 
RECORDED  BY  a  VAL I DATION_POI NT  will  be  the  logical  OR  of  the  data  to  be 
collected  for  each  of  the  PERFORMANCE_REQUIREMENTs  that  use  the  VALIDATION_ 
POINT.  Subsequently,  each  specified  requirement  is  translated  into  a 
PASCAL  procedure  which  is  written  as  the  TEST  for  that  PERFORMANCE_REQUIREMENT. 

At  this  point  in  the  methodology  for  developing  performance  require¬ 
ments,  the  ASSM  data  base  should  contain  the  following  additional  performance- 
related  RSL  statements,  described  in  the  order  in  which  they  would  generally 
be  entered. 

1)  The  DATA  and  FILEs  accessible  from  those  appearing  on  the 
nets  will  have  been  declared  as  input  to  each  terminal 
VALIDATION_POINT  through  use  of  the  RECORDS  relationship. 

2)  Additional  VALIDATION_POINTs  required  by  each  PERFORMANCE_ 
REQUIREMENT  will  have  been  defined  and  appropriately  located 
as  nodes  on  the  net  STRUCTURES.  DATA  and  FILEs  RECORDED  BY 
these  VALIDATION_POINTs  will  have  been  declared. 

3)  Each  VALIDATION_PATH  CONSTRAINED  BY  each  PERFORMANCE_REQUI RE- 
MENT  will  have  been  defined  and  a  PATH  structure  for  each 
VALIDATION_PATH  will  have  been  defined  by  declaration  of  the 
VALIDATION_POINTs  and  EVENTS  appearing  on  the  net  STRUCTURES 
between  the  initial  and  terminal  VALIDATION_POINTs. 

4)  A  TEST  will  have  been  written  for  each  PERFORMANCE_REQUIREMENT. 

An  example  of  the  RSL  statements  in  the  ASSM  at  this  point  is  provided 
in  Figure  4-2  for  the  energy-ner-image  constraint  discussed  in  preceding 
sections. 

4.3  DEFINE  SUPPLEMENTAL  VALIDATION  POINTS  AND  DATA 

A  VALIDATION  POINT  not  only  defines  a  point  in  the  processing  flow 
at  which  data  are  collected  for  evaluation  against  a  PERFGRMANCE_REQUIRE- 
MENT,  but  also  may  identify  the  point  along  the  nets  at  which  the  measure¬ 
ment  is  made  for  compliance  with  the  system  performance  specification. 
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ORIGINATING_REQUIREMENT:  radar_re SOURCE  .CONTROL _R. 

OF  SCR  I PT I  ON : 

"DPSPR  PARAGRAPH  3.2.4(B)*  RESOURCE  CONTROL ♦  STATES  THAT 
("THE  DPS  SHALL  ALLOCATE  RADAR  COMMANDS  SO  THAT  NOT  MORE 
THAN  ( TBD )  JOULES  ARE  COMMANDED  PER  IMAGE*  NOR  MORE  THAN 
( TBD)  KILOWATTS  OR  ( TRD>  PULSES/SECOND  FOR  ALL  IMAGES  IN 
TRACK.'*)  "  . 

PERFORMANCE-REQUIREMENT:  ENERGY-PER-IMAGE • 

TFST:  <*  THE  TBD  BELOW  MUST  BE  REPLACED  BEFORE  EXECUTION*) 

-CONST 

ENEPGY_LIMIT= (TBD)  t 
VAR 

IMAGE.ENERGY:  REAL! 

BEGIN 

ENERGY_PER_IMAGE:=TRUEI 

FOR  EACH  C2-IMAGE-HANDOVER  RECORDING 

DO 

IMAGE_ENEPGY:=0.0 

FOR  EACH  RAOAR_COMMAND_OUTPUT_POINT  RECORDING 

SUCH  THAT  (RADAR_COMMANO_OUTPUTJ>OINT.TARGET_ID= 

C2_I MAGE-HANDOVER. HO-ID) 

DO 

SFLECT  FIRST  FROM  ST ART  I NG-PO I  NT . WAVEFORM-TABLE 
SUCH  THAT  <RAOAR_COMMAND..OUPtJT_POlNT.RADAR_TYPE  = 
STARTING-POINT. WF-MAME) I 
IF  FOUND  THEN 

IMAGE-ENERGY := IMAGE-ENERGY ♦ 

STARTING-POINT.WF-CHARACTERISTICSI 

ENDI 

ENDFOREACHI 

IF  ( IMAGE-ENERGY>ENERGY_LIMIT)  THEN 
E NFRGY— PER— IMAGE  :  =FAl.5E  I 
ENDFOREACH 
END  I ". 

TRACED  FROM:  ORIGINATING-REQUIREMFNT :  RADAR-RE SOURCE -CONTROL-#* 

PFRF0RMANCE-REOUIREMENT :  PULSES-PER-SECOND. 

TRACED  FROM:  0RI6INATING-REQUIREMENT :  RADAR-RESOURCE-CONTROL-.B* 

PERFORMANCE-REQUIREMENT :  PAO!ATED_POWER. 

TRACED  FROM:  ORIGINATING-REQUIREMFNT:  RADAR-RE SOURCE-CONTROL-.B • 


Figure  4-2  Performance  Requirements  Statements  Representation  at 
the  Completion  of  SREM  Step  -  Define  Data  and  Tests 
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DECISION:  RADAR.RESOURCE .control _B 1 . 
problem: 

"DPSPR  PARAGRAPH  3.2.4(B)*  STATEMENT  ( "THE  DPS  SHALL 
ALLOCATE  RADAR  COMMANDS  SO  THAT  NOT  MORE  THAN  ( TBD)  JOULES 
ARE  COMMANDED  PER  IMAGE*... "3  ALLOWS  EOR  THREE  POSSIBLE 
INTERPRETATIONS  IN  DETERMINING  THF  POINT  AT  WHICH  THE 
PERFORMANCE  .REQUIREMENT  TEST  IS  APPLIED. 11 . 

ALTERNATIVES'. 

"1.  THE  ALLOCATOR  SHALL  ASSIGN  TRACK  RATES  SUCH  THAT  THE 
CUMULATIVE  SUM  OF  THE  ENERGY  FOR  EACH  IMAGE  OVER  THE 
ENGAGEMENT  (THE  PROOUCT  OF  ALLOCATED  PULSE  PATE* 

FNERGY  PER  PULSE*  AND  DURATION  OF  ALLOCATION)  SHALL 
NOT  EXCEED  (TBD)  JOULES. 

?.  THE  ENERGY  REQUIRED  BY  THE  RADAR  COMMANDS  TRANSMITTED 
ACROSS  THE  INTERFACE  TO  THF  RADAR  SHALL  NOT  EXCEED 
(TBD)  JOULFS, 

3.  THE  FNERGY  REQUIRED  BY  THE  RADAR  COMMANDS  ACTED  UPON 
BY  THF  RADAR  AS  DETECTED  BY  THE  DPS  IN  THE  RETURN 
MESSAGES.  SHALL  NOT  EXCEED  ( TRD)  JOULFS.". 

CHOICF: 

THE  FNERGY  REQUIRED  BY  THE  RADAR  COMMANDS  TRANSMITTED 
ACROSS  T«E  INTERFACE  TO  THE  RADAR  SHALL  NOT  EXCEED 
(TBD)  JOULES  SHALL  RE  TESTED  FOR  COMPLIANCE  A.T  THE 
INPUT  TO  THE  OUTPUT  INTERFACE:  R ADAR.OUT . " . 

TRACED  FROM:  ORlGINATING_REQUIRFMENT :  RADAR. RESOURCE.CONTROL.B . 
TRACES  TO:  PERFORMANCF.REQUIREMENT:  FNERGY.PER. IMAGE. 

VALIDATION_POINT:  RADAR_COMMAND_OUTPUT.POINT. 

rfcoros: 

data:  TARGET.ID* 
data:  RAOAR.TYPE. 

TRACED  FROM:  DECISION:  RADAR.RESOURCE_CONTROL.Rl. 

VAL IOAT ION.POINT :  C2.IMAGE .HANDOVER, 

RECORDS:  DATA:  HO.ID. 

TRACED  FROM: 

ORIGINATING.REQUIREMENT:  RADAR.RE SOURCE .CONTROL.B . 
PERFORMANCE.REQUIREMENT:  energy.per.image, 

VALinATION^POTNT:  ST  ART ING.PO I NT • 

RECORDS :  FILE:  WAVE FORM. TABLE • 

TRACED  FROM:  PPRFORMANCE.REQUIREMFNT :  ENERGY.PER.IMAGE. 


Figure  4-2  Performance  Requirements  Statements  Representation  at 
the  Completion  of  SREM  Step  -  Define  Data  and  Tests 
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valioation_path:  radar_command„output. 

CONSTRAINED  BY:  PFRFORMANCE_REQU IPEMENT :  ENERGY_PER_IMAGE . 
TRACED  FROM: 

ORIGINATING.REQUIREMENT:  RADAP.RESOURCE -CONTROL. 9 * 

DECISION:  RADAR_RESdURCE_CONTROl._Rl. 

PATH: 

VALIDATION-POINT:  R AD AR.COMMAND_OUTPUT .POI NT 
FNO. 

VALIDATION-PATH:  T2-HAND0VER.C0MMAN0-INPUT. 

CONSTRAINED  BY:  PFRFORMANCE-REQUIREMENT :  ENFRGY-PER-IMAGE. 
TRACED  FROM:  ORIGINATING -REQUIREMENT :  RADAR_RESOURCE_CONTROL_R 
path: 

VALIDATION-POINT:  C2-IMAGE.HAN00VER 
FNO. 

VALIDATION .PATH:  RADAR_WAVEFORM_PROPERT I ES . 

CONSTRAINED  8Y :  PERFORMANCE-REQU I REMENT :  ENERGY.PER-IMAGE. 
TRACED  FROM:  ORIGINATING-REQUIREMFNT:  RADAR_RESOUf<CE_CONTROL_.B 
path: 

VALIDATION-POINT:  STARTING-POINT 
FND. 


Figure  4-2  Performance  Requirements  Statements  Representation  at 
the  Completion  of  SREM  Step  -  Define  Data  and  Tests 
(Continued) 


Through  identification  of  the  initial  VALIDAT I0N_P0INT  on  a  VALIDATION_PATH 
(i.e.,  the  earliest  VALIDATION  POINT  along  the  R-NET  and  SUBNET  STRUCTURES 
representing  the  functional  requirement  to  which  the  performance  constraint 
applies),  the  requirements  engineer  may  define  the  PERFORMANCE_REQUIREMENT 
in  terms  of  performance  between  the  initial  and  terminal  VAL I  DAT I ON  PO I  NT  s . 
Processing  of  synchronous  threads  (i.e.,  elementary,  stimulus-response 
processing)  will  frequently  employ  such  paths,  as  will  requirements  which 
reflect  the  decomposition  and  partitioning  of  system  performance  specifications 
to  a  level  below  that  where  the  constraint  is  defined  to  be  applicable  to 
the  DPS  treated  as  a  "black-box."  For  example,  in  a  complete  BMD  system, 
constraints  on  discrimination  may  be  specified  in  terms  of  target  classifi¬ 
cation  relative  to  the  object  state  vector  obtained  at  the  output  of  the 
tracking  function.  In  such  cases,  a  VALIDATION_POINT  would  be  located  at 
the  entry  point  of  the  net  which  defines  the  functional  requirements  for 
discrimination  to  identify  the  starting  point  of  the  PERFORMANCE  REQUIREMENT 
TEST. 

Early  identification  of  a  specific  TEST  for  a  PERFORMANCE_REQUIREMENT 
within  the  development  process  implies  a  capability  to  define,  early  in 
development,  data  needed  for  testing  that  has  no  counterpart  in  the  functional 
requirement  description  of  the  system.  On  a  synchronous  thread,  these  data 
are  commonly  collected  at  an  early  VAL I DAT I 0N_P0 I NT ;  however,  on  an 
asynchronous  thread,  it  may  be  inconvenient  to  collect  and  correlate  data 
from  two  VALIDATION  POINTS  appearing  on  disjoint  paths  or  net  structures. 
Therefore,  the  requirements  engineer  defines  DATA  items,  element  types 
and  in  extreme  cases  R-NET  or  SUBNET  STRUCTURES  with  attributes  ARTIFICIALITY: 
VALIDATION  to  convey  the  needed  DATA  to  a  VAL IDATI0N_P0INT  at  which  it  may 
be  extracted  for  a  TEST.  For  example,  in  Track  Loop  suppose  that  a 
performance  constraint  establishes  a  maximum  delay  time  between  the  arrival 
of  a  track  return  message  at  the  INPUT  INTERFACE  RADAR_IN  and  the  time  at 
which  the  data  contained  in  the  return  message  is  incorporated  in  the  data 
which  makes  the  command  message  that  passes  to  the  rac^r  through  the 
OUTPUT_INTERFACE  RADAROUT.  The  connection  between  tne  two  interfaces  is 
asynchronous  due  to  scheduling  operations  and  use  of  the  IMAGE_IN  TRACK 
ENTITY  TYPE  in  R-NET  SKEDR.  Since  no  one-to-one  correlation  exists 
between  the  return  received  and  the  command  issued,  a  validation  DATA 


item,  RETURNJIME,  can  be  defined  and  ASSOCIATED  WITH  the  ENTITYJTYPE 
IMAGE  INJRACK.  This  DATA  item  would  be  OUTPUT  FROM  the  UPDATE_STATE 
ALPHA,  where  it  would  be  set  equal  to  the  current  value  of  engagement 
time,  and  would  be  RECORDED  BY  a  VAL I DATI0N_P0I NT  located  on  the  R_NET 
XMIT  R  immediately  preceding  the  OUTPUT_INTERFACE  RADAR_0UT. 

Note  that  information  conveyed  by  an  element  type  with  ARTIFICIALITY 
VALIDATION  must  be  provided  in  the  real-time  process  when  it  is  being  used 
to  validate  the  process  design  against  the  system  performance  specifica¬ 
tion.  In  practice,  element  types  so  defined  represent  a  counterpart  to 
the  hardware  test  point,  and  like  their  equivalent  may  be  retained  in  the 
fielded  system  by  management  directive. 

At  this  point  the  requirements  engineer  has  completed  the  steps  of 
the  methodology  for  developing  performance  requirements.  The  ASSM  data 
base  has  been  built  with  liberal  use  of  the  TRANSLATOR  and  RADX  segments 
of  REVS  to  insure  the  accuracy  and  completeness  of  each  PERFORMANCE^ 
REQUIREMENT  description.  The  requirements  engineer  is  now  in  a  position 
to  begin  the  compilation  debug  process  and  execution  of  the  analytic 
simulator  for  verification  and  refinement  of  the  PERFORMANCE_REQUIREMENT 
statements. 
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PART  Ii  -  MANAGEMENT  APPROACH 


5.0  INTRODUCTION 

One  of  the  major  benefits  in  using  the  SREM  tools  and  techniques  dis¬ 
cussed  in  Part  I  to  develop  software  requirements  is  that  the  process  is 
inherently  manageable.  The  technical  approach  consists  of  specific  activi¬ 
ties  which  have  well  defined  beginnings  and  endings,  and  the  high  degree 
of  automation  provided  by  RFVS  allows  a  degree  of  management  visibility 
which  is  ordinarily  not  attainable  in  the  specification  development 
process. 

The  three  sections  which  follow  discuss  the  three  important  aspects 
of  managing  software  requirements  engineering: 

•  Defining  Measurable  Milestones 

•  Planning 

•  management  Control . 

The  emphasis  in  these  sections  is  to  describe  the  management  considera 
tions  which  are  unique  to  the  application  of  SREM.  Just  as  Part  I  will  not 
make  good  requirements  engineers  out  of  technicians,  Part  II  will  not  make 
good  managers  out  of  clerks.  Even  good  managers,  however,  are  helpless  if 
they  do  not  have  the  means  to  establish  visibility  and  control.  Part  II 
is  intended  to  give  the  experienced  manager  an  understanding  of  how  the  tool 
and  techniques  of  SREM  can  be  used  to  establish  and  maintain  a  sound  manage¬ 
ment  plan  for  the  specification  of  software  requirements. 


f 


6.0  DEFINING  MEASURABLE  MILESTONES 

The  key  to  successful  management  of  software  requirements  engineering 
is  the  establishment  of  meaningful,  clear,  and  measurable  milestones.  There 
is  a  tendency  to  treat  requirements  generation  as  a  level  of  effort  problem, 
since  the  job  of  milestone  definition  is  not  easy  and  requires  a  technical 
understanding  of  the  work  to  be  performed.  Establishing  milestones  such  as 
"Processing  Performance  Specification  -  First  Draft",  "Processing  Perfor¬ 
mance  Specification  -  Second  Draft",  etc.,  may  provide  clarity  and  a  super¬ 
ficial  measurability  but  does  not  establish  a  meaningful  or  effective 
management  tool . 

Management  of  an  activity  using  the  Software  Requirements  Engineering 
Methodology  (SREM)  can  be  extremely  effective  because  the  discipline 
inherent  in  SREM  permits  segmenting  the  effort  into  activities  which  have 
meaningful  and  measurable  terminations.  An  example  approach  to  defining 
SREM  related  milestones  is  illustrated  in  this  section.  The  milestones 
are  divided  into  two  groups: 

Group  1  -  Functional  software  requirements  development. 

Group  2  -  Functional  software  requirements  validation. 

An  overview  of  the  SREM  activities  described  in  Section  3  is  shown 
in  Figure  6-1.  Simply,  software  requirements  are  generated  by  transforming 
corresponding  system  requirements.  The  initial  activity  is  a  preliminary 
evaluation  and  organization  of  the  source  specifications.  This  is  accomplished 
by  drawing  the  R-Nets.  Once  this  activity  is  complete,  parallel  development 
of  the  segmented  requirements  can  proceed.  As  the  requirements  segments  are 
developed,  they  are  entered  into  the  REVS  data  base  (ASSM)  from  which  they  are 
drawn  for  static  evaluation.  When  the  ASSM  entry  for  all  software  require¬ 
ments  is  complete,  a  dynamic  simulation  (functional  and/or  analytic)  can  be 
generated  and  a  dynamic  evaluation  performed  to  complete  the  requirements 
validation.  At  various  points  in  this  process,  problems  with  the  source 
specifications  can  be  identified  and  fed  back  to  the  system  engineer. 
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6.1  SOFTWARE  REQUIREMENTS  DEVELOPMENT 


Starting  with  the  initial  set  of  milestones,  the  natural  beginning  of 
software  requirements  development  is  the  acceptance  of  source  specifica¬ 
tions.  This  is  not  a  final  acceptance.  That  can't  take  place  until  the 
software  requirements  are  validated.  Rather,  the  software  requirements 
manager  must  establish  that  the  source  specifications  provide  a  sufficient 
base  from  which  the  requirements  engineering  can  proceed.  Ideally  this 
base  is  complete,  clear,  and  correct.  In  complex  systems,  such  as  those 
required  for  ballistic  missile  defense,  establishing  an  ideal  base  is  a 
goal  seldom  achieved.  The  best  that  can  be  hoped  for  is  to  identify  those 
places  where  the  source  specifications  are  incomplete,  unclear,  or  of 
questionable  correctness,  and  then  proceed  with  risk  --  but  under  control. 
Immediate  feedback  is  provided  to  system  engineering  on  the  deficiencies 
found  in  the  source  specifications  so  that  answers  can  be  developed. 

Th^  initial  set  of  milestones  shown  in  Figure  6-2  is  designed  to 
accomplish  two  objectives.  The  obvious  purpose  of  specification  review 
is  to  establish  specification  acceptance  and  identify  exceptions  to  and 
conditions  on  this  acceptance.  The  second  objective  is  to  begin  the  actual 
software  requirements  development.  Drawing  the  R-Nets  is  used  to 
organize  the  source  specifications  and  to  establish  a  basis  for  commitment 
of  the  individuals  responsible  for  writing  the  software  requirements.  It 
is  this  commitment  which  is  the  best  measure  of  progress  through  the 
acceptance  of  source  specifications. 

As  discussed  in  Section  3,  the  R-Nets  typically  require  some  creative 
engineering  before  they  can  be  completed.  Therefore,  this  initial  review 
will  not  normally  result  in  fully  complete  R-Nets.  It  should,  however 
identify  what  information  or  assumptions  are  needed  for  completion.  These 
are  described  in  RSL  as  DECISIONS  as  shown  In  Figure  6-3.  At  this  point, 
only  the  statement  of  the  PROBLEM  and  the  TRACES  TO  attributes  are  entered 
(and  maybe  the  ALTERNATIVES).  Each  DECISION  is  reviewed  with  system  engi¬ 
neering  to  verify  that  the  source  specifications  have  been  correctly 
interpreted  before  the  ALTERNATIVES  and  CHOICE  are  completed. 
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Criteria  for  this  initial  review  should  include: 

•  Can  you,  the  reviewer,  develop  software  requirements  from 
the  information  contained  in  the  source  specifications? 

a  What  changes  or  additional  information  would  make  your  job 
easier? 

a  Are  the  performance  requirements  present  and  understandable? 

a  Do  the  source  requirements  appear  to  be  overly  restrictive 
( i . e . ,  at  too  low  a  level  of  detail)? 

For  each  milestone  of  Figure  6-3  the  Software  Requirements  Manager 
or  his  Configuration  Control  Board  (CCB)  is  responsible  for  recognizing 
the  milestone  completion.  On  a  very  large  software  development  project 
a  hierarchy  of  secondary  milestones  may  be  necessary.  These  lower  level 
milestones  should  be  under  the  cognizance  of  lower  level  managers  and  are 
represented  to  the  Software  Requirements  manager  only  in  aggregate  as 
higher  level  milestones. 

The  first  effort  is  aimed  at  completing  each  R-NET  to  the  ALPHA 
level.  Most  of  this  activity  can  be  segmented  to  the  R-NET  and  SUBNET 
levels.  However,  it  is  advisable  to  assign  one  individual  the  responsi¬ 
bility  to  coordinate  the  data  base  This  is  a  third  party  action  to 
bring  about  agreement  on  interfaces  between  R-NETS  and  SUBNETS.  In  addi¬ 
tion,  this  data  base  approval  activity  should  include  analysis  of  the  data 
base  to  eliminate  dead  (unused)  or  orphaned  (unset)  data  entities. 

To  a  very  large  project,  the  Requirements  Manager  may  also  wish  to 
have  an  independent  group  transcribe  the  source  specifications  into  ORIGINATING_ 
REQUIREMENTS  and  enter  them  Into  the  ASSM  and  then  place  them  under  configu¬ 
ration  control.  Since  this  step  is  critical  to  the  validity  of  traceability 
audits  later  on,  this  independent  entry  may  be  justified.  On  smaller  projects, 
this  may  not  be  appropriate. 

Again,  an  opportunity  exists  for  the  software  requirements  engineer  to 
feed  back  problems  to  the  system  engineer  via  DECISIONS.  While  there  Is  a 
tendency  to  identify  and  communicate  problems  in  a  continuous  manner,  this 
destroys  the  baseline  and  gives  the  entire  project  a  drifting  feeling.  It 
is  therefore  necessary  to  set  up  specific  milestones  for  DECISIONS.  The 
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Figure  6-3  Sample  Decisions  from  Track  Loop 
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ones  recommended  here  seem  to  be  a  minimum  set  and  can  be  augmented  to 
tailor  the  process  to  a  specific  project. 


After  documenting  all  known  source  specification  problems  the  soft¬ 
ware  requirements  can  proceed  with  internal  baselining.  This  baselining 
culminates  with  formal  approval  of  the  Software  Requirements  Engineering 
(SRE)  Configuration  Control  Board  (CCB).  The  use  of  the  Requirements 
Engineering  and  Validation  System  (REVS)  enforces  quality  control.  Because 
of  this,  the  CCB  baselining  can  address  higher  level  issues  of  whether  or 
not  the  software  requirements  adequately  reflect  the  intent  of  the  source 
specifications  and  to  what  extent  the  software  requirements  provide  an 
appropriate  base  for  process  design.  The  former  issue  can  be  resolved 
by  analyzing  the  DECISIONS  against  the  source  specification.  These  can 
be  categorized  into  those  with  major  effect  on  software  requirements 
and  those  with  minor  effect  on  the  software  requirements.  Baselining  may 
be  deferred  until  certain  major  problems  are  resolved  and  the  number  of 
minor  problems  is  reduced  to  an  acceptable  level.  The  visible  act  of 
deferring  a  major  milestone  can  bring  considerable  pressure  to  work  problems 
expeditiously. 

6.2  SGFTWARE  REQUIREMENTS  VALIDATION 

The  major  effort  in  software  requirements  engineering  is  in  the  vali¬ 
dation  phase.  Validation  begins  with  static  evaluation  which  is  a  check  of 
data  consistency.  Validation  also  includes  the  development  of  BETA 
(functional)  models  and  simulator  to  test  the  software  requirements  for 
dynamic  consistency.  This  is  primarily  a  test  to  verify  that  the  specified 
logic  is  correct  in  a  dynamic  sense.  With  appropriate  functional  models 
(BETAs),  a  BETA-level  simulation  can  also  be  used  to  examine  and  predict 
system  level  performance  as  a  function  of  data  processing  performance. 

Validation  may  include  the  development  of  GAMMA  (analytic)  models 
and  simulator.  GAMMA  models  are  non-real-time  algorithms  which  input  and 
output  the  specified  data  at  its  elemental  level.  The  purpose  of  the 
GAMMA  simulator  is  to  demonstrate  that  a  design  solution  to  the  software 
requirements  exists  at  least  if  the  real  time  constraint  is  relaxed. 
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A  sample  activity  network  for  requirements  validation  is  shown  in 
Figure  6-4.  The  first  effort  establishes  that  the  completed  R-Nets  at 
the  ALPHA  level  are  fully  complete  and  consistent.  When  this  is  established, 
the  DECISIONS  related  to  the  source  specifications  and  the  resulting  soft¬ 
ware  requirements  are  reviewed  and  approved.  Following  this,  the  require¬ 
ments  are  completed  to  BETA  level  as  described  in  Section  3,  and  the  BETA 
models  and  the  BETA  data  base  are  reviewed  and  approved.  When  the  BETA- 
level  dynamic  performance  evaluation  is  completed  and  all  DECISIONS  have 
been  approved  (milestone  2.11),  then  a  new  requirements  baseline  is 
established  at  milestone  2.12  and  the  functional  requirements  are  complete. 

In  a  project  in  which  there  are  well  known  design  solutions  available 
for  all  the  processing  specified,  the  functional  requirements  validation 
would  end  with  milestone  2.12,  the  updated  baseline.  However,  in  BMD 
systems,  and  in  fact  in  most  modern  large  scale  systems,  there  are  algorithm 
issues  which  present  considerable  development  risk.  If  this  is  the  case, 
the  requirements  validation  is  not  complete  until  the  computational  feasi¬ 
bility  of  the  requirements  is  established.  This  is  called  the  analytic 
feasibility  demonstration.  The  purpose  of  this  phase  is  to  demonstrate 
through  simulation  that  it  is  possible  to  process  the  specified  input  data 
to  obtain  the  specified  results.  The  sequence  of  activities  for  this 
phase  of  the  effort  begins  with  milestone  2.13  and  ends  with  a  second  base¬ 
line  release  of  the  requirements  at  milestone  2.22.  The  intervening  mile¬ 
stones  are  similar  to  those  for  functional  validation  discussed  earlier. 

The  final  event  is  the  formal  release  of  the  internally-approved  specifica¬ 
tion  (milestone  2.23). 

6.3  SUMMARY 

The  foregoing  is  an  example  of  how  the  SREM  activities  described  in 
Section  3  can  be  related  to  measurable  and  meaningful  milestones.  An 
identical  approach  can  be  used  for  the  activities  described  in  Section  4. 

The  activity  networks  presented  here  are  not  intended  to  be  a  universal 
SREM  management  plan  in  which  one  can  fill  in  dates  and  names  and  be  done. 
Every  program  is  different  as  is  each  engineering  organization.  Therefore, 
there  cannot  be  a  universal  management  plan  any  more  than  there  can  be  a 


Sample  Activity  Network  for  Software  Requirements  Validation  (Continued) 


Figure  6-4  Sample  Activity  Network  for  Software  Requirements  Validation  (Continued) 
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7.0  PLANNING 


Planning  for  software  requirements  engineering  using  SREM  is  unique 
in  two  respects.  First,  several  of  the  automated  features  of  REVS  ran  have 
a  strong  effect  on  scheduling.  For  example,  the  automatic  simulation 
generation  produces  a  simulation  in  much  less  time  than  conventional  manual 
techniques.  Second,  very  little  data  exists  on  the  cost  and  schedule  aspects 
of  implementing  SREM. 


With  these  two  thoughts  in  mind  it  seems  appropriate  to  identify  those 
planning  characteristics  peculiar  to  SREM,  organize  them  into  a  simple 
model  and  evaluate  that  model.  This  approach  has  the  promise  of  producing 
some  quantitative  measures  for  SREM  planning. 


To  date,  there  is  no  usable  data  on  which  to  base  a  firm  cost  and 
schedule  model  for  SREM.  The  Track  Loop  System  used  as  the  example  problem 
in  Sections  3  and  4  was  an  experimental  model  used  to  test  and  refine  the 
methodology  steps,  RSL,  and  the  REVS  software.  Consequently,  the  TLS  soft¬ 
ware  requirements  were  developed  several  times  and  the  effect  of  prior 
knowledge  cannot  be  factored  out  of  the  data. 

7.1  PRELIMINARY  GUIDELINES 

From  the  TLS  development  experience,  some  preliminary  guidelines  can 
be  established.  These  guidelines  form  the  basis  of  a  cost  and  schedule 
estimation  technique. 

1)  The  overall  technical  coordination  of  the  activity  must  be 
the  responsibility  of  one  person.  In  a  small  problem  such  as 
TLS,  this  person  can  also  be  a  "working"  engineer.  In  a 
large  project,  this  technical  management  function  is  a  full 
time  job  by  itself.  This  is  analogous  to  the  chief  of  a 
chief  programmer  team. 

2)  The  initial  R-Net  development  effort  should  not  be  broken 
down  beyond  the  point  of  assigning  one  engineer  to  each 
R-Net.  The  number  of  R-Nets  can  be  initially  estimated  to 
equal  the  number  of  input  interfaces  plus  the  number  of 
independent  (asynchronous)  output  interfaces. 

3)  The  development  of  BETA  and  GAMMA  models  and  performance  TESTS 
Is  essentially  an  engineering  modeling  and  programming  effort. 
These  can  be  estimated  by  conventional  software  estimation  tech¬ 
niques  except  that  the  integration  effort  is  greatly  reduced 
through  the  use  of  the  automatic  simulation  feature  of  REVS. 
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While  these  guidelines  are  very  preliminary  and  general,  they  form  a  better 
basis  for  estimating  than  the  current  practice  of  allocating  10  to  20  per¬ 
cent  of  the  estimated  software  cost  (derived  by  cost-per-instruction  times 
estimated-number-of-instructions)  to  the  requirements  development. 

7.2  COS'!  MODEL 

The  formalism  of  the  RSL  expression  of  software  requirements  and  the 
methodical  approach  of  developing  and  validating  them  using  SREM  suggests 
that  a  formal  cost  model  can  be  developed.  A  proposed  starting  point  for 
such  a  model  follows  the  general  form  of 

Kx£ci  •  D,  •  Nl 

where 

K  =  a  weighting  factor  equal  to  the  cost  per  typical  element 

(equivalent  to  dollars-per-instruction  in  software  development). 

n  ■  number  of  elements  (ALPHAS,  etc.). 

C.j  =  the  relative  complexity  of  the  ith  element. 

Di  =  the  relative  newness  (state-of-the-art)  of  the  ith  element. 

X.  L. 

Ni  =  the  size  of  the  itn  element. 

It  appears  that  the  cost  of  the  requirements  is  sensitive  to  the 
following  elements: 

§  Overall  logic  and  data-flow  complexity  which  can  be 

reasonably  represented  by  the  ALPHAS.  ALPHAS  are  chosen 
because: 

1)  their  INPUT  and  OUTPUT  relationships  are  a  direct 
indicator  of  the  data  flow  complexity,  and 

2)  the^e  is  almost  a  one-to-one  relationship  between  an 
ALPHA  and  a  logic  node  or  node-branch  on  an  R-Net. 

•  Functional  Models  -  BETAs. 

•  Analytic  Models  -  GAMMAs. 
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•  Performance  Allocations  -  VALIDATION  PATHS. 

•  Performance  Measures  -  TESTs. 

•  Simulator/Driver  Integration  -  MESSAGES. 

One  additional  factor  is  the  firmness  of  the  source  requirements  which 
directly  effects  the  number  of  times  the  requirements  engineering  work 
will  have  to  be  redone. 

A  model  of  the  cost  of  developing  and  validating  the  software  require 
ments  is  then  given  by  the  following: 


The  parameters  in  this  model  are  defined  in  Table  7.1. 

This  model  estimates  the  cost  of  direct  man-hours  only.  Costs  for 
management,  ODC  (Other  Direct  Charge,  such  as  travel),  and  computer  time 
must  be  added. 

Not  only  can  such  a  cost  model  be  used  to  estimate  costs  before  SRE 
actually  starts,  it  can  also  be  used  during  SRE  to  project  cost  to  complete 
This  is  done  by  updating  the  estimated  parameters  with  real  values  as  they 
become  available.  Cost  control  is  discussed  in  Section  8. 

7.3  SCHEDULING 

Having  completed  a  top  down  cost  estimate,  that  result  can  be  used 
to  obtain  a  gross  schedule  of  activities.  The  cost  model  must  first  be 
partitioned  into  six  parts. 

HA  =  SR  KA  £  CA.  °A.  NA. 

i=l  1  1  1 
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Table  7.1  Definition  of  Symbols  Used  in  Cost  Model 


DEFINITION 


A.  L_ 

Complexity  factor  for  i  M  ALPHA.  (Value  of  minimum  complexity 
is  unity.) 

Complexity  factor  for  itl1  BETA.  (Value  of  minimum  complexity 
is  unity.) 


i.  i_ 

Complexity  factor  for  i Ln  GAMMA.  (Value  of  minimum  complexity 
is  unity.) 

X  L_ 

Complexing  factor  itn  PATH  decomposition.  (One-to-one 
correspondence  between  a  performance  requirement  in  the 
source  specification  to  a  PATH  is  unity;  more  complex 
relationships  are  higher.) 


1L 

Complexity  factor  of  itn  TEST.  (Value  of  minimum  complexity 
is  unity.) 


Newness  factor  for  i^  ALPHA.  (Value  for  completely  off- 
the-shelf  is  0,  completely  new  is  1.) 

X  L. 

Newness  factor  for  i  BETA.  (Value  for  completely  off-the- 
shelf  is  0,  completely  new  is  1.) 

Newness  factor  for  ith  GAMMA.  (Value  for  completely  off-the- 
shelf  is  0,  completely  new  is  1.) 

Newness  factor  of  ith  PATH  decomposition.  (Known  decomposi¬ 
tions  are  unity;  if  trade-off  analyses  are  required,  the 
factor  is  higher.) 

Newness  factor  of  itfl  TEST.  (Completely  off-the-shelf  is  0, 
completely  new  is  unity.) 


Newness  factor  for  SETS.  (A  fully  tested,  well  documented, 
and  previously  used  SETS  is  1;  others  are  higher.) 


Weighting  factor  for  ALPHA  development. 


Weighting  factor  for  BETA  development. 


Weighting  factor  for  GAMMA  development. 


Weighting  factor  for  PATH  decomposition. 
Weighting  factor  for  TEST  development. 


7-4 


-"***11 


Table  7.1 


Definition  of  Symbols  Used  in  Cost  Model 


(Continued) 


SYMBOL 


M 


definition 

Weighting  factor  for  simulation  integration. 

Number  of  I/O  messages. 

Size  of  i  ^  ALPHA  in  lines  of  RSL. 


Number  of  ALPHAS  (BETAs  and  GAMMAs). 
P  Number  of  VALIDATION  PATHs. 

t  Number  of  TESTs. 

^  Slze  °f  ALPHA  in  lines  of  RSL. 

nB.  Size  of  ith  beta  in  lines  of  RSL. 

\  Slze  °T  GAMMA  in  lines  of  RSL. 

NTf  Size  of  ith  TEST  in  lines  of  RSL. 


Softness  of  system  requirements 
greater  than  1.) 


(Firm  is  1,  soft  is 


I 

i 

i 


I 


hb  =  sr  kb  Z  cb.  db.  nb. 

i=l  1  1 


hg  =  sr  kg  Z  cg.  dg.  ng. 

1-1  1  1  1 


p 

HP  =  SR  KP  2Z  Cp.  '  Dp. 

i=l  1  1 


HT  '  SR  KT  ZZ  CT.  '  °T.  '  NT, 
i-1  1  1  1 


HS  ~  SR  KS  DS  M 


Then  four  estimates  are  extracted  as  follows: 


Note  that  H  =  H-,  +  H2  +  H3  +  H^. 

Looking  at  the  milestones  in  Section  5  these  are  grouped  into  three 
sets.  The  first  is  associated  with  the  R-NET  development  and  includes  mile¬ 
stones  1.1  through  1.4.  The  second  set,  2.1  through  2.6,  is  related  to 
BETA  modeling.  The  final  set  includes  the  remaining  milestones,  2.7  through 
2.23,  and  Is  roughly  related  to  GAMMA  modeling.  Figure  7-1  shows  the  three 
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sets  of  activities  related  to  these  milestones  crudely  spread  over  time 
periods  ,  T2  and  T3  expressed  in  work  hours.  Then  effort  divided  by  time 
is  equivalent  to  manloading. 

For  activities  related  to  R-NET  development  the  effort  in  hours  is 
approximately  H, .  Assuming  a  constant,  flat-loaded  activity  the  loading 
then  is  H-j /T j .  A  small  group  should  be  working  this  phase  of  the  require¬ 
ments  development.  Even  on  a  very  large  project  no  more  than  five  engineers 
should  be  directly  involved  in  the  R-NET  development.  Assuming  10  percent 
for  direct  support  and  10  percent  for  management  support  this  translates 
into  a  constraint: 

T1  > 

Schedule  times  T2  and  T3  can  also  be  roughly  estimated  by  examining  values 
for  H2/T2  and  A3/T3  noting  that  these  two  activities  should  overlap.  For 
a  small  SRE  project  the  following  might  apply: 

H-|  =  80  man  hours 
H2  =  400  man  hours 
H3  =  800  man  hours 

Then,  the  planning  might  select 

T-j  =  40  work  hours 
T2  =  80  work  hours 
T3  =  160  work  hours 

giving  a  manloading  as  shown  in  the  top  part  of  Figure  7-2.  Since  it  is 
usually  unrealistic  to  expect  adequate  performance  from  short  assignments, 
a  better  approach  is  to  smooth  the  total  manpower  curve  somewhat.  This 
is  done  in  the  bottom  part  of  Figure  7-2. 

Having  obtained  a  rough  manpower  curve  it  is  now  necessary  to  establish 
a  detailed  milestone  schedule.  For  a  small  project  such  as  the  one  just 
discussed  it  is  probably  better  to  lump  some  of  the  serial  milestones  so  that 
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a  week-by-week  measurement  is  adequate.  For  the  sake  of  demonstration  the 
complete  set  of  milestones  will  be  laid  out  on  the  seven-week  schedule  shown 
in  Figure  7-2  (bottom).  Figure  7-3  shows  the  detail  milestone  schedule. 

The  two  major  activities  are  the  BETA  and  GAMMA  modeling  which  occur  in 
parallel.  For  a  small  project  many  of  the  review  and  approval  milestones 
can  be  accomplished  simultaneously. 

The  schedule  in  Figure  7-3  shows  no  slack  time.  An  end-to-end  schedule 
with  no  slack  time  is  dangerous  even  on  a  small  project.  Since  the  SRE 
activities  are  laid  out  on  a  seven-week  or  thirty-five  day  period  with  no 
slack,  then  10  percent  or  about  4  days  is  a  conservative  amount  of  slack. 

The  slack  should  be  inserted  after  the  most  vulnerable  milestones  so  that 
the  overall  schedule  is  minimally  perturbed  if  a  milestone  is  missed. 

Figure  7-4  shows  a  revised  schedule  with  slack  time  (dashed)  protecting  key 
milestones.  With  slack  time  on  the  parallel  BETA  and  GAMMA  branches  addi¬ 
tional  flesibility  is  achieved  since  manpower  not  required  during  one  slack 
activity  can  be  shifted  to  the  other  branch. 

Note  that  the  schedules  do  not  provide  the  typical  periods  for  docu¬ 
ment  preparation,  review,  and  publication.  The  automatic  documentation 
features  of  REVS  reduce  the  need  for  these  activities.  The  technical  and 
management  review  of  the  requirements  is  accomplished  using  REVS  ge:, crated 
reports.  Once  approved,  the  generation  of  the  final  documentation  is  simply 
one  more  computer  run  using  the  appropriate  RADX  directives  with  REVS. 

The  planning  process  has  been  illustrated  using  the  milestones  defined 
in  Section  b  for  the  activities  discussed  in  Section  3.  The  planning  of  the 
Section  4  activities  is  accomplished  in  a  similar  manner  using  the  H4  term 
in  the  cost  breakdown. 
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8.0  MANAGEMENT  CONTROL. 


The  Software  Requirements  Engineerinq  activity  must  interface  with 
other  activities  during  the  system  development  phase.  Figure  8-1  explains 
the  major  interests  shared  by  SRE  with  these  other  activities.  The  key 
interactions  may  be  summarized  as  follows: 

•  SRE  supports  SE  in  system  definition  by  accepting  the  speci¬ 
fications  and  pointing  out  deficiencies. 

•  SRE  may  question  the  subsystem  allocation  because  of  implemen¬ 
tation  problems. 

•  SRE  participates  in  the  overall  system  cost/schedule  planning 
and  control  by  providing  status  data  to  SE  and  visibility  to 
Process  Design. 

•  SRE  must  work  with  the  other  subsystem  engineering  activities 
to  define  interfaces  to  a  functional  level.  Process  Design 
can  work  to  design  the  detail  interfaces.  When  a  referee 

is  needed  the  SE  must  decide  interface  issues. 

t  SRE  defines  the  processing  via  software  requirements  which 
may  be  modified  if  real-time  implementation  is  a  problem. 


8.1  CONTROL  MECHANISMS 

Management  of  SREM  can  be  viewed  as  a  two-level  process.  REVS  pro¬ 
vides  certain  direct,  automatic  control  of  the  product  under  development 
(the  software  requirements).  As  described  in  Table  8.1  this  frees  manage¬ 
ment  to  focus  on  higher  level  issues  and  the  implementation  of  REVS.  With 
a  validated  REVS,  implementation  of  its  control  features  is  completely 
mechanical  and  can  be  delegated  with  confidence.  In  particular,  in  Table 
8.1,  we  note  the  following  observations: 

•  At  each  level  the  manager  can  focus  on  intent,  softness  of 
decisions,  level  of  detail  and  schedule  performance. 

f  At  the  BETA,  GAMMA  and  PATH/PERFORMANCE  levels,  cost  perfor¬ 
mance  becomes  important.  Overkill  must  be  avoided  by  main¬ 
taining  pressure  to  use  the  simplest,  cheapest  models  which 
will  do  the  job.  (Thus  level  of  detail  is  an  issue  here  also.) 

•  At  the  GAMMA  level  the  manager  must  assess  real-time  feasi¬ 
bility  even  though  the  GAMMA  models  are  not  real-time. 
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Figure  8-1  Interests  Shared  by  SRE 
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•  Note  all  of  the  control  which  REVS  gives  cheaply  and 
quickly.  Previously,  managers  had  to  strain  to  get  this 
kind  of  visibility. 

The  major  managerial  issues  identified  in  Table  8.1  require  mechanisms 
outside  of  REVS.  These  are  the  more  widely  used  managerial  controls,  and  are 
much  more  effective  when  based  on  the  timely,  complete,  and  organized  infor¬ 
mation  provided  by  REVS.  The  kinds  of  control  mechanisms  used  for  these 
issues  are  shown  in  Table  8.2  and  are  summarized  below: 

•  Internal  reviews  can  be  used  to  establish  confidence  in  the 
software  requirements  by  addressing  items  checked  in  the  Table. 

•  Starting  with  a  parametric  cost  model,  projected  cost  can  be 
estimated  as  actual  parameter  values  are  determined  (e.g., 
number  and  complexity  of  ALPHAs). 

•  Earned  value  as  a  measure  of  progress  toward  each  milestone 
can  be  used  in  the  C-SPEC  sense  to  evaluate  cost/schedule 
performance  in  a  continuous  fashion.  Earned  value  can  be 
quantified  by  using  number  of  ALPHAS,  BETAs,  GAMMAs,  PATHS, 
and  TESTs  weighted  by  complexity  factors. 

•  The  milestone  schedule  is  a  standard  schedule  performance 
control  best  implemented  by  public  display. 

•  Reviews  with  the  system  engineer  should  help  understand 
questions  of  intent  and  softness  of  decisions  plus  adequacy 
of  level  of  detail. 

•  The  process  designer  should  be  involved  in  reviews  of  level 

of  detail  and  real-time  feasibility  (includes  storage  capacity). 

8.2  CHANGE  CONTROL 

The  process  of  change  control  is  a  critical  one  on  a  large,  complex 
system  development  activity.  Figure  8-2  shows  how  collected  decisions  are 
folded  into  the  baseline  as  scheduled  updates.  The  updates  are  inserted 
at  points  in  the  schedule  where  they  are  likely  to  have  significant  inputs 
from  within  the  SRE  activity  and  from  System  Engineering  and  Process  Design. 
They  also  follow  specific  measures  of  the  software  requirements,  namely  the 
initial  dynamic  evaluation  and  the  initial  feasibility  demonstration. 


V;, 


n 

m 


m 

% 


g 


l 


8-4 


8-5 


SECOND  HAJOR  UPDATE  (AlPHA/BETA/G/UtlA) 


8.3  SELLING  THE  SOFTWARE  REQUIREMENTS 

Both  the  System  Engineer  and  Process  Designer  must  "buy  off"  the  soft¬ 
ware  requirements.  SR EM  possesses  key  features  which  shouid  assist  the  SRE 
manager  ,n  effecting  the  buy-off.  These  are  expiained  in  Tabie  8.3  in  te™s 
answers  to  concerns  of  both  System  Engineering  and  Process  Design. 
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9.0  CONCLUSIONS 


» 


This  manual  has  attempted  to  explain  both  the  technical  and  management 
considerations  in  the  development  and  validation  of  software  requirements 
using  the  tools  and  techniques  of  SREM.  The  engineering  and  management 
principles  explained  here  are  not  new  --  they  are  the  result  of  hundreds 
of  man-years  cc  experience  in  large-scale  r?al-time  software  development. 

The  discipline  of  RSL  and  the  power  of  REVS  are  new,  as  is  the  formalization 
of  the  detailed  steps  to  be  followed  in  their  use. 

This  manual  will  not  make  instant  engineers  or  managers  out  of  in¬ 
experienced  people.  It  will,  however,  guide  the  experienced  engineer  and 
manager  in  the  application  of  RSL,  REVS,  and  SREM  techniques  to  obtain  a 
software  requirements  specification  which  is  superior  in  terms  of  the 
qualities  of  a  good  specification  discussed  in  the  opening  Section. 


APPENDIX  A 


RSL  TERMINOLOGY 


CLCMINT.TrPtl  ALPHA 

(*  A  PROCESSING  STEP  IK  THE  FUNCTIONAL  REQUIREMENTS 
OOHAIN,  *), 

STRUCTURE  APPLICABILITY!  NET, 

ELEHENT.TYPEl  DATA 

<•  A  SINGLE  ITCH  BP  SET  BF  DATA  THAT  I!  SPECIFIED 
AND  THAT  WILL  EITHER  BE  REQUIRED  IN  THE 
REAL-TIne  SOFTWARE  BP  IS  NEEDED  F 8 R 
DESCRIPTIVE  PURPOSES ,  O. 

ELEMENT^ TYPE i  OECISIBN  '  • 

(«  THE  OECISIBN  THAT  HAS  BEEN  HADE  TO  ENABLE 

REOUIREHENTS  T 6  BE  TAKEN  FROM ■ THE  OFSPR  T8  THE  PPR, 
THIS  HEAN3  THAT  THE  REQUIREMENTS  ARE  NOT  SIMPLY 
ALLOCATED,  BUT  HAVE  BEEN  SUBJECTED  TP 
DERIVATION,  *), 

ilcmekt.typci  ENT!TY_CLASS 

{•  A  GENERAL  CLASS  OF  ’OBJECTS"  IN  THE  PEAL  W0PLD 
OUTSIDE  THE  DATA  PROCESSING  SYSTEM  l  NO  WHICH  IS 
IMPORTANT  T 8  IT,  FBR  EXAMPLE,  AN  EMITY.CLASS 
MIGHT  BE  RVS  8R  INTERCEPTORS,  THE  I NTIT Y„TYPES 
MIGHT  BE  DETECTION,  P  0 1  ENT  I AL„RV ,  It  ENTIFIED_RV, 
ETC,  *). 

fLEMENTjrrpei  entity^type 

C*  A  SPECIFIC  TYPE  OF  "OBJECT"  IN  THE  fEAL  WORLD 

OUTSIDE  THE  DATA  PROCESSING  SYSTEM  / KD  WHICH  IS  BF 
IMPORTANCE  Tfl  IT,  WHEN  A  SPECIFIC  1 YPE  OF  "OBJECT" 
IS  OETERHINEO  TO  EXIST  IN  AN  ENTITY  CLASS,  files 
AND  DATA  MAY  BE  TEMPORARILY  CREATED  TO  MAINTAIN 

TMPBPMAT  J**M  AflWHT  JT> 

ELEMENTS YPE |  EVENT 

(*  AN  IOENTIFIEO  POINT  THAT  EXISTS  in  the  PROCESSING 
BF  ONE  OR  MORE  R,>ETS  OR  SUBNETS  ANt  WHICH  MAY 
CAUSE  THE  ENABLEMENT  OF  AN  R„NET.  *5, 

STRUCTURE  APPLICABILITY!  NET, 

STRUCTURE  APPLICABILITY!  PATH, 

ELEMENT.TYPEl  FILE 

(*  AN  AGGREGATION  OF  INSTANCES  OF  DATA,  EACH  INSTANCE 
OF  WHICH  IS  TREATED  IN  THE  SAME  MANNER,  *), 

ELEMENT.TYPEl  INPUTllNTERFACE 

(•  A  "PORT"  BETWEEN  THE  DATA  PROCESSING  SYSTEM 
AND  THE  REST  OF  THE  BMD  SYSTEM  WHICH  ACCEPTS 
DATA  FROM  THE  OTHER  SYSTEM  (E,C,  THE 
RADARJTETURNS).  *>. 

STRUCTURE  APPLICABILITY!  NET, 

eLEMENT.TVPEl  HCS5AGE 

{*  AN  AGGREGATION  of  DATA  AND  FILES 

THAT  PASS  THROUGH  AN  INTERFACE  AS  A  LOGICAL 
UNIT,  •). 

ILIMENT.TYPEl  originatingIrecuirement 

(a  the  HIGHER  level  CDPSPR)  REQUIREMENT  FROM  WHICH 
LONER  LEVEL  REQUIREMENTS  (THE  ONES  DESCRIBED  IN 
THE  RSL)  are  traceable,  *>. 

ELEMENT.TYPCl  OUTPUT..  INTERFACE 

<*  A  "PORT"  BETWEEN  THE  DATA  PROCESSING  SYSTEM 
AND  THE  REST  OF  THE  BHD  SYSTEM  WHICH  TRANSMITS 
OATA  TO  THE  OTHER  SYSTEM  (E.G,  THE 
RAOAR_COMMANOS>,  *), 

STRUCTURE  APPLICABILITY!  NET, 
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PfffiCSDItO  PiOl  BtM&W*  SUMS 


CL£MENT_TYP||  PERFORM ANCE.Rtnu I «EME NT 

(«  AN  ANALYTIC  PERFORMANCE  REQUIREMENT  eR 
NON. STIMULUS-RESPONSE  TIMING  REQUIREMENT 
WHICH  IS  TO  BE  MET  BY  THE  REAL-TIME  SOFTWARE,  *>. 

IUMCNT..TYPCI  R>£T 

(•  THE  ORDER  OF  LOGICAL  PROCESSING  STEPS  THAT  MUST  8E 
PERFORMED,  AN  R_N£T  MAY  CONTAIN  ANDS,  0R3,  AND 
FOR  EACH  NODES  I  ?T  MUST  BE  ENABLED  and  TERMINATED, 
THE  PROCESSING  STEPS  APE  ALPHAS  OR  SU6NETS  MmJCH 
MAY  BE  E YPANDED  INTO  LOMER  LEVELS  OF  DETAIL,  AN 
R”NET  HAY  ALSO  CONTAIN  VALIOATION^POINTS,  EVENTS, 
AND  INTERFACES.  •), 


ILCMENT.TYPEl  reference 

(*  SOURCE  MATERIAL  FtR  REQUIREMENTS,  *), 
CLEMENT.TYPEi  SUBNET 

(•  THE  ORDER  OF  LOGICAL  PROCESSING  STEFS  THAT  MUST  PE 
PERFORMED  in  OROER  TO  PERFORM  the  REQUIREMENTS  OF 
THE  PROCESSING  STEP  THAT  REPRESENTS  IT  AT  THE  NEXT 
HIGHER  LEVEL,  *), 

STRUCTURE  APPLICABILITY!  NET, 


ELCHENT..TYPEI  SUBSYSTEM 

(•  A  PART  OF  THE  0MD  SYSTEM  (SUCH  AS  RADAR)  WHICH 
COMMUNICATES  WITH  THE  OATA  PROCESSING  SYSTEM,  *), 


ELEMENT.TYPEl  SYNONYM 

<*  A  synonym  is  mepely  an  alternate  name  that 

CAN  BE  USED  IN  PLACE  of  THE  PRIME  NAME,  IT 
15  USED  AS  AN  ABBREVIATION  IN  MOST  CASE 3, 
BUT  MAY  BE  USED  FOR  OTHER  REASONS  ALSO, 
NOTE!  IN  AN  <!LfcMfcNT  1 YMt  LlST>,  "ALL* 
ALWAYS  IMPLIES  "ALL  EXCEPT  SYNONYM",  *),, 


ELEMENT..TYPEI  UNSTRUCTURE  D_REOUIREment 

<*  A  REQUIREMENT  THAT  MUST  BE  PASSED  TO  THE  DESIGNER  OF 
THE  REAL-TIME  COOE  BUT  THAT  DOES  NOT  FIT  INTO  THE 
STRUCTURED  FRAHEHORK  PROVIDED  BV  R5L .  THIS  ELEMENT 
MIGHT  BE  USED  BECAUSE  THE  REQUIREMENT  IN  QUESTION  IS 
TOO  UNIQUE  TO  JUSTIFY  DEFINITION  OF  A  NEW  TYPE  OF 
ELEMENT,  A  NEW  RELATIONSHIP,  OR  A  NEW  ATTRIBUTE,  IT 
ALSO  MIGHT  BE  USED  BECAUSE  THE  REQUIREMENTS  ANALYST 
DOES  NOT  CARE  TO  DESIGN  A  N £w  CONCEPT  TO  FIT  THE 
REQUIREMENT,  OR  BECAUSE  THE  REQUIREMENT  IS  CLEARLY 
A  DESIGN  LIMITATION  THAT  SHOULD  BE  DESCRIBED 
IN  ENGLISH  TEXT,  (AN  EXAMPLE  OF  THE  LAST 
REASON  MIGHT  HE  PRECLUSION  OF  USING  A 
MULTIPROCESSOR  WITH  ASSOCIATIVE  MEMORY,)  *), 


CLEMENT.TYPEl 


VALIDATION  path 

(*  THE  PATH  OF  PROCESSING  OVER  WHICH  THE  QUANTITATIVE 
VALIDATION  TESTING  WILL  BE  PERFORMED,  *), 


CLIMENT.TYPEl  validaticn.point 

(*  A  LOGICAL  POINT  IN  THE  PROCESSING  AT  WHICH  TIMING, 
VALUE,  OR  PRESENCE  OATA  MUST  BE  OBTAINABLE  IN  THE 
REAL-TIME  SOFTWARE  IN  ORDER  TO  VALIDATE  THAT  THE 

REQUIREMENTS  have  been  fulfilled,  *), 

STRUCTURE  APPLICABILITY!  NET, 

STRUCTURE  APPLICABILITY!  PATH, 


ELEMENT  TYPE!  VERSION 

(•  THE  AGGREGATION  OF  REQUIREMENTS  THAT  ARE  TO  ' 
APPLY  AS  A  UNIT  TO  THE  OATA  PROCESSING 
SYSTEM  AT  A  PARTICULAR  TIME,  LOOP.l, 

L00P_2,  ETC.,  ARE  VERSIONS,  AS  IS  AN  IOC 
SYSTEM,  •), 
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RELATIONSHIP!  ASSQC  I  *TF9 

(*  TELLS  WHICH  DATA  AND  FILES 

C0*£  I'JTB  EXISTENCE  WHEN  tm£  DATA 
PROCESSING  SYSTEM  ( SOME  ALPHA)  CREATES  AN 
Instance  be  an  entity.class  or  an  r.net  is 

ENABLED,  *), 

COMPLEMENTARY  RELATIONS*^  j  ASSOCIATED  {"WITH"), 

SUBJECT  I  ENTITY.TYPE#  £Nf ItyIclaSS, 

SBJECTl  DATA,  FILE. 

PELATIONShIPi  COMPOSES 

(*  TELLS  WHICH  ENTITY^TYPES  ARE  MEMBERS  OF  AN 
ENTITY.CLASS,  » 5 , 

COMPLEMENTARY  RELATIONSHIP!  COMPOSED  (•OF"), 

SUBJECT!  CNTITY.TYPE, 

OBJECT!  ENTITVICLASS, 

RELATIONSHIP!  CONNECT’S  (*TO») 

(*  TELLS  which  SUBSYSTEM  THE  I NPUY.INT  ERF*CE  OR 
OUTPUT.INTEPFACE  COMMUNICATES  WITH,  ■  ). 
COMPLEMENTARY  RELATIONSHIP!  CONNECTED  CTO*), 

SUBJECT!  iNPUTllNTERFACE,  OUTPUT” INTERFACE, 

OBJECT!  SUBSYSTEM, 

RELATIONSHIP!  CONTAINS 

(*  TELLS  THE  IDENTITY  OF  EACH  CONSTITUENT  PART  OF  EACH 
INSTANCE  IN  A  FILE,  A  DIRECT  IWPLT  MENTATION  IN 
SOFTWARE  WOULO  USE  THIS  RELATIONSHIP  TO  GIVE  THE 
HAKE-UP  OF  RECORDS  IN  FILES,  a), 

COMPLEMENTARY  RELATIONSHIP!  CONTAINED  ("IN"). 

8UBJECT!  FILE, 

OBJECT!  DATA, 

RELATIONSHIP!  CONSTRAINS 

(A  IDENTIFIES  TO  WHICH  V i L I D A T 10 N^P A  TH { 3 )  THE 
PERFORMANCE  REQUIREMENT  APPLIES,  a), 

COMPLEMENTARY  RELATIONSHIP!  CONSTRAINED  ("BY"), 

SUBJECT!  PERFORMANCE. REQUIREMENT, 

OBJECT!  VALIOATION.PATH, 

RELATIONSHIP!  CREATES 

(a  TELLS  WHICH  PROCESSING  STEPS  CREATE  THE  INSTANCE 
OF  AN  ENTITYlCLASS,  a), 

COMPLEMENTARY  RELATIONSHIP!  CREATED  ("BY"), 

SUBJECT l  ALPHA4 
OBJECT!  ENTITY.CLASS, 

RELATIONSHIP!  DELAYS 

{a  THE  ENABLEMENT  OF  R.NETS  BY  THE  BBJECT  EVENT  IS 
POSTPONED  F«R  THE  AMOUNT  OF  TIME  SPECIFIED  BY 
THE  OATA,  a), 

COMPLEMENTARY  RELATIONSHIP!  DELAYED  (•BY*) , 

SUBJECT!  DATA, 

ABJECT!  EVENT, 

RELATIONSHIP!  DESTROYS 

(a  TELLS  which  PROCESSING  STEPS  DESTROY  AN 
INSTANCE  OF  THE  ENTITYlCLASS,  a), 

COMPLEMENTARY  RELATIONSHIP!  DESTROYED  (*BY*) , 

SUBJECT!  ALPHA^ 

OBJECT!  ENTITY.CLASS, 

RELATIONSHIP!  ENABLES 

(a  WM£N  THE  EVENT (S)  IS  (ARE)  PASSED  THROUGH  BY  THE 
CONTROL  FLOW  ON  AN  R>ET»  OR  WHEN  DATA  ARE 
AVAILABLE  at  i.H  INTERFACE  (AS  DEFINEO  IN  THE 
INTERFACE  DEFINITION),  THE  FUNCTIONAL  PROCESSING 
INOICATEO  ON  THf  R.NfT  CAN  BE  BEGUN,  a), 
COMPLEMENTARY  RELATIONSHIP!  ENABLED  ("BY*), 

SUBJECT!  EVENT,  INPUT. INTERFACE, 

OBJECT!  R.NET, 


i  equates  r's*3 

<*  DEFINES  AS  A„T£PnatE  n**F  FOR  AS  FLCAfST.  THE 

tfiJCC"  IS  r.  At_  (  r  0  jur  bcj»c  n*m£  ,  T>-F  SUBJECT  NAME 
CAS  se  USED  FOR  INPUT  T  “  THE  A$jM,  ?  UT  ALL 
RELATIONSHIPS*  ATTRIBUTES,  **D  STRUC  TUBES  AS 
OfPIstO  APE  ACTUALlV  CoASACTESISTIC!  OF  THE  PRIME 

SAHF,  •). 

-f  >.0)  r  «-k*  iflv  pflaT  IfSSMiPi  EQUATED  ("TO"!. 
iwf-.ECTl  SYNONYM, 

jpjecti  all, 

pi L ATlesSHlPi  EXPLAINS 

(•  THE  REFERENCE  EXPLAINS  THE  BACKGROUND 

INFORMATION  AE3U-  THE  OBJECT  ELEMENTS.  a), 
.T'HPirHES'TiPY  »fLATISN«HTP|  EXPLAINED  ( *  BY  *  )  , 

.  I  °  !  T  T  T  f  PEFroCNCE, 

CoJECTi  ALL  ExCLPt  REFERENCE. 

«■  4v:«nsm;pj  forms 

(•  INOICATES  the  ALPHA  WHICH  DEFINES  A  MESSAGE 
TO  BE  PASSED  THROUGH  an  OUTPUT^ INTERFACE.  *3, 
:-*'>0LC“ENTABY  RELATIONSHIP!  FORCED  C »PY ■  >  . 

I. EJECT!  * .0u A , 

OH’iCTt  hessaCE. 

Pf  t.ATIONShlP!  IHPLEHENT! 

(*  TELL'  The  VERSIONS  TP  WHICH  THE  ELEMENT,  AS 
DESCRIBED,  APPLIES,  *3. 

:*''\!U!NTARV  RELATIONSHIP!  IMPLEMENTED  (■BY*), 

Uu-.Ht  T|  ALL  EXCEPT  VERSION, 

OBJECT!  VERSION, 

RELATIONSHIP!  INCLUOES 

(*  InOIC*TES  T*  -  nltRANCHlC*L  RELATIONS**?  BETWEEN 
Data,  if  A  INCLUDES  3,  Then  OBTAINING  A  HILL 

OBTAIN  8.  •  ), 

C*HPI. ENfNTARV  RELATIONSHIP!  INCLUDED  CIN*), 

SUBJECT |  DATA, 

SDJ&C  T  j  DATA, 

RELATIONSHIP!  INPUTS 

(«  INDICATES  THAT  THE  NAMED  ELEMENT  INPUTS  THE 
OBJECT  ELEHENT(S),  *), 

•“O-PLEHENTABY  RELATIONSHIP!  INPUT  (  *T0  ■  >  , 

CUPJfCT!  ALPHA,  VALIDATION^POINT, 

OBJECT  I  DATA,  FILE. 

RELATIONSHIP!  MAKES 

C*  TELLS  TH|£  IDENTITY  OF  DATA  AND  FILES  THAT 
MAKE  UP  A  MESSAGE,  «), 

COMPLEMENTARY  RELATIONSHIP!  MADE  (•BY*). 

SUBJECT!  DATA,  FILE, 

BBJFCTl  MESSAGE, 

RELATIONSHIP!  ORDERS 

<•  THE  ELEMENT  ON  WHICH  THE  INSTANCES  ARE 
ORDERED  IN  A  FILE,  •). 

COMPLEMENTARY  RELATIONSHIP!  ORDERED  ( *8 Y*  )  , 

SUBJECT!  DATA, 

OBJECT!  FILE, 

RELATIONSHIP!  OUTPUTS 

(•  INDICATES  The  NAMFD  ELEMENT  OUTPUTS  THE 
OBJECT  ELEHENT(S),  *3, 

COMPLEMENTARY  RELATIONSHIP!  OUTPUT  (■FROM"), 

SUBJECT!  ALPHA. 

OBJECT!  DATA,  FILE, 


A- 6 


RELATIONSHIP!  passes 

<*  INDICATES  THE  INFORMATION  WHICH  PASSES  THROUGH 
THE  INTERFACE.  *). 

COMPLEMENTARY  RELATIONSHIP!  PASSED  ( "THROUGH" ) , 

SUBJECT!  INPUT’lNTERFACE,  OUTPUT^ INTERFACE. 

OBJECT!  MESSAGE. 

RELATIONSHIP!  SETS 

(*  TELLS  WHICH  ALPHA  SETS  THE  ENTITY.TYPE  OF  AN 
INSTANCE  IN  AN  ENTITY_CLASS.  *), 

COMPLEMENTARY  RELATIONSHIP!  SET  ( "BY" ) , 

SUBJECTl  ALPHA4 
OBJECTl  ENTITY.TYPE, 

RELATIONSHIP |  TRACES  CTO*) 

(*  TELLS  THE  HIGHER  LEVEL  (ORIGINATING)  REQUIREMENT 
FROH  WHICH  THE  ELEMENT  WAS  TRACED  (ALLOCATED), 

A  DEFAULT  ORIGINATING  REQUIREMENT  IS  "NONE", 

WHICH  INDICATES  THAT  The  ELEMENT  IS  DERIVED, 

WE  WOULD  EXPECT  THAT  THE  ATTRIBUTE 
•ARTIFICIALITY"  WOULD  HAVE  VALUE 
•ARTIFICIAL"  IF  THE  ELEMENT  IS  TRACED  FROM 
■NONE",  HOWEVER,  THIS  may  BE  UNTRUE  IN 
CASES  WHERE  an  ARBITRARY  HEURISTIC  MUST  BE 
EMPLOYED.  *). 

COMPLEMENTARY  RELATIONSHIP!  TRACED  ("FROM"), 

SUBJECTl  ORIGINATINr,_REQUIREMENT,  DECISION, 

OBJECTl  ALL  EXCEPT  fl«IGlNATlNG_R£QUIREM£NT, 

ATTRIBUTE!  ALTERNATIVES 

(*  THE  ALTERNATIVES  THAT  HAVE  BEEN  ENVISIONED  TO 
RE50LVE  THE  PROBLEM,  *), 

APPLICABLE  TO|  DFCTSTON, 

VALUE!  TEXT, 

ATTRIBUTE  I  ARTIFICIALITY, 

APPLICABLE  TO!  ALL. 

VALUEl  ARTIFICIAL 

(•  THE  ELEMENT  HAS  BEEN  DEFINED  FOR  EXPLANATORY  OR 
EXECUTABILITY  PURPOSES  IN  THE  REQUIREMENTS 
STATEMENT  and  NEED  NOT  BE  PRESENT  IN  THE  REAL-  THE 
SOFTWARE.  •). 

VALUE!  IHPlEmEnOreCISELV 

<*  THE  ELEMENT  MUST  BE  IMPLEMENTED  IN  THE  REAL-TIME 
SOFTWARE  EXACTLY  AS  DEFINED)  NO  CH/NGE5  SHOULD  BE 
CONSIDERED  UNTIL  PERMISSION  IS  OBTAINED  FROM  THE 
REQUIREMENTS  ANALYST,  t), 

VALUEl  IMPlEMENtIapproxihatELY 

(*  THE  ELEMENT  MUST  BE  IMPLEMENTED  IN  TH!:  REAL-TIME 
SOFTWARE,  BUT  THE  PRECISE  IMPLEMENTATION  IS  LEFT  TO 
THE  PROCESS  DESIGNER,  OF  COURSE,  THE  DETAILED 
IMPLEMENTATION  MUST  BE  VALIDATED  BY  THE 
REQUIREMENTS  ANALYST,  «), 

VALUE!  VALIDATION 

<*  THE  ELEMENT  IS  NECESSARY  FOR  DESCRIBING 
PERFORMANCE  REQUIREMENTS  BUT  IS  NOT 
REQUIRED  IN  THE  REAL-TIME  SOFTWARE,  *), 

ATTRIBUTE!  BETA 

(*  THIS  PROVIDES  THE  PROCEDURAL  CODE  (WHICH  IS  NOT 
INTERPRETED  BY  THE  RSI  PROCESSORS)  FOR  FUNCTIONAL 
MODELS,  IT  IS  PASSED  TO  THE  SIMULATION  GENERATOR 
AND,  SUBSEQUENTLY,  TO  THE  COMPILER,  •). 

APPLICABLE  TOl  ALPHA, 

VALUEl  TEXT, 


ATTRIBUTE!  CHOICE 

(*  THE  DECISION  FRBH  AMONG  THE  ALTERNATIVES  WITH  THE 
RATIONALE  FOR  THE  DECISION,  .*), 

APPLICABLE  TO |  OECISION, 

VALUEl  TEXT, 

ATTRIBUTE  I  COMPLETENESS, 

applicable  toi  all. 

VALUEl  INCOMPLETE 

(#  THE  ELEMENT'S  DESCRIPTION  IS  KNOWN  TO  BE 

INCOMPLETE,  THEREFORE.  REA0ER3  SHOULD  BE  AWARE 
THAT,  EVEN  If  ALL  RELATIONSHIPS,  ATTRIBUTES,  AND 
STRUCTURES  ARE  STATED,  THE  ELEMENT  IS  STILL 
INCOMPLETE.  INFORMATION  ABOUT  THE  ELEMENT  SHOULD 
BE  EHPLOYED  ONLY  AT  THE  USEP'S'OWN  RISK,  *), 

VALUEl  CHANGEABLE 

<•  ALTHOUGH  ALL  RELATIONSHIPS,  ATTRIBUTES,  AND 

STRUCTURES  "AY  BE  DEFINED  FOR  THE  ELEMENT,  SOME  OP 
THEM  WILL  PROBABLY  BE  CHANGED,  INFORMATION  ABOUT 
THE  ELEHENT  IS  BELIEVED  TO  BE  CORRECT,  BUT  IT  IS 
SUBJECT  TO  CHANGE,  *), 

VALUE  I  COMPLETE 

(•  THE  ELEMENT'S  DESCRIPTION  SHOULD  BE  ASSUMED  TO 
BE  COMPLETE  ANO  HILL  PROBABLY  NOT  CHANGE.  *). 

ATTRIBUTE  I  DESCRIPTION 

(*  TEXTUAL  DESCRIPTION,  •), 
applicable  toi  all. 

VALUEl  TEXV, 

A7TRIBUTEI  ENTERED.BY, 

APPLICABLE  TOi  ALL. 

VALUEl  TEXT 

<•  THE  IDENTITY  OF  THE  L*ST  PERSON  TO  ENTER 
INFORMATION  ABOUT  THE  ELEMENT,  *>. 

ATTRIBUTE  I  EXTRACTOR 

{*  PROCEDURAL  CODE  IDENTIFYING  FOR  WHICH  INSTANCES 
OF  FILES  ANO  ENTITIES  THE  DATA  INPUT  TO  THE 
VALIDATION^POINT  IS  TO  BE  EXTRACTED  IN  THE 
REAL-TIME  SOFTWARE,  •  >, 

APPLICABLE  TO «  VAlIOATION_POINT, 

VALUEl  TEXT, 

ATTRIBUTE  I  GAMMA 

(•  THIS  PROVIDES  THE  PROCEDURAL  CODE  (WHICH  IS  NOT 
INTERPRETED  BY  RSL  PROCESSORS)  FOR  ANALYTIC 
MODELS,  IT  IS  PASSED  TO  THE  SIMULATION  GENERATOR 
ANO,  SUBSEQUENTLY,  TO  THE  COMPILER.  •  >, 

APPLICABLE  toi  alpha, 

VALUEl  TEXT, 

attributei  initialivalue 

(•  THE  INITIAL.VALUE  A  data  item  IS  recuired  to 
HAVE  IN  the  IMPLEMENTED  SOFTWARE.  THIS  VALUE 
HILL  BE  ASSUMED  BY  THE  DATA  ITEM  WHEN  IT  COMES 
INTO  EXISTENCE  IN  A  SIMULATION,  •), 

AT  PLIC ABLE  TO  I  DATA, 

VALUEl  NUMERIC. 

VALUE!  TEXT, 
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ATTRIBUTE!  LOCALITY. 

APPLICABLE  TO  I  DATA,  PILE. 

VALUE!  GLOBAL 

(a  GLOBAL  OATA  ANO  PILES  HAY  BE 
ASSOCIATED  WITH  ENTITyItyPES  OR 
ENTITY-CLASSES  OR  HAY  BE  IN  THE 
GLOBAL  DATA  BASE,  *). 

VALUE!  LOCAL 

(a  LOCAL  OATA  AND  PILES  ARE 

created  and  initialized  Por  iach  enablement 

OP  AN  R_N£T,  A). 

ATTRIBUTE!  HA XIMUM_TIME . 

APPLICABLE  TO |  VALIDATION^ PATH, 

VALUE!  NUMERIC 

(*  THE  MAXIMUM  TIME  THAT  CAN  BE  TAKEN  TC  TRAVERSE  THE 
VALIDATION  PATH,  a), 

ATTRIBUTE!  MAXIMUH_VAL,UE 

(•  THE  MAXIMUM..VALUE  APPLIES  TO  DATA  VALUES  AND 
employs  the  UNITS  stated  in  the  units 
ATTRIBUTE,  *). 

APPLICABLE  TO  i  OATA. 

VALUE!  NUMERIC. 

ATTRIBUTE!  MINIMUM_TIME 

( a  THE  MINIMUM  TIME  THAT  CAN  BE  TAKEN  TO  TRAVERSE  THE 
VALIDATION  PATH,  a), 

APPLICABLE  TO  |  VALIOATION.PATH, 

VALUE!  NUMERIC. 

ATTRIBUTE!  MINIHUM_V*LUE 

(a  THE  MIN:muH_VALUE  applies  TO  DATA  VALUES  AND 
EMPLOYS  THE  UNITS  IN  THE  UNITS  ATTRIBUTE,  *). 
APPLICABLE  TO!  DATA, 

VALUE!  NUMERIC. 

ATTRIBUTE  I  PROBLEM 

(a  THE  PROBLEM  THAT  HAS  LED  70  THE  NEED  MR  A 
DECISION,  a), 

APPLICABLE  TO!  DECISION, 

VALUE!  TEXT, 

ATTRIBUTE!  RANGE 

(A  THE  RANGE  OP  THE  DATA  IS  ENUMERATED  HERE. 

IT  IS  MEANINGFUL  ONLY  IP  ENUMERATION  IS  THE 
VALUE  OP  TYPE,  a), 

APPLICABLE  T 0 1  OATA, 

VALUE!  TEXT 

(A  THE  ALLOWED  VALUES  ARE  SEPARATED  BY  COMMAS,  a), 
ATTRIBUTE!  RESOLUTION 

(A  DESCRIBES  THE  REQUIRED  MAXIMUM  VALUE  OP  THE  LEAST 
SIGNIFICANT  BIT  POR  THE  DATA  IN  UNl‘ 0  DESCRIBED  IN 
THE  UNITS  ATTRIBUTE.  *). 

APPLICABLE  TOl  DATA, 

VALUE!  NUMERIC, 

ATTRIBUTE!  TEST 

(a  PROCEDURAL  CODE  WHICH  DEFINES  THE  ClMPUTATIONS 
NECESSARY  TO  TEST  THE  SATISFACTION  i;p  A 
PERFORMANCE_REOUIREMENT  USING  DATA  INPUT  TO 
VALIDATI8N>0INTS.  *), 
applicable  TOl  PERPORMANCE.REQUIREMENT, 

VALUE!  TEXT. 


ATTRX8UTC  t  TYPE 


(•  THE  TYPE  FOR  THE  DATA  ITEH8  WHICH  APE  REFERENCED 
BN  PlNETS  0«  ABE  USED  IN  BETA  OR  GAMMA 
SIMULATIONS,  *), 

APPLICABLE  TO |  OATA, 

VALUE  I  BEAL. 

VALUE  I  INTEGER. 

VALUEj  boolean, 

VALUE  t  ENUMERATION 

(•  THE  ALLOWEO  VALUES  MUST  BE  SPECIFIED  IN  THE 
RANGE  ATTRIBUTE.  *). 

ATTRIBUTE!  UNITS  . 

(*  THE  CONFIGURATION  MANAGEMENT  MANAGE*  MUST  CREATE 
THE  ATTRIBUTE  VALUES  THAT  MAY  ‘BE  EMPLOYED  IN 
DESCRIBING  YHE  RETIREMENTS  FOR  T«E  DATA 
PROCESSING  SYSTEM  UNDER  CONS  IDER  ATItiN,  *), 
APPLICABLE  TO  I  DATA,  VALIDATION^ PATH, 

VALUE!  NAMED. 

ATTRIBUTE!  USE 

(•  THE  APPLICABILITY  OF  TYPE  AND  RANGE  ARE 
SPECIFIED  IN  THE  USE.  *), 

APPLICABLE  TO!  DATA, 

VALUE!  BETA. 

VALUE!  GAMMA, 

VALUE!  BOTH 

(«  BOTH  BETA  ANO  GAMMA  *), 


DATA!  CLOCK_TIME 


(*  A  PREDEFINED  DATA  ITEM  WHICH  INCREMENTS  AT  THE 
SAME  RATE  AS  ENGAGEMENT  TIME,  EXCEPT  FOR  ITS 
INITIAL_VALUE  WHICH  IS  ARBITRARY,  CIOCK.TIME  HAY 
BE  REGARDED  AG  ENGAGEMENT  TIME,  IT  HAS  NO  CLOCK 
ERROR,  *), 


LOCALITY!  GLOBAL. 
TYPE!  REAL. 

UN.ITSI  SECONDS, 
USE!  BOTH, 


DATA!  FOUND 

C*  A  PREDEFINED  OATA  1TEM  WHICH  IS  SET  TO  EITHER 
TRUE  OR  FALSE  AFTER  EACH  SELECT  IN  A  BETA  OR 
GAMMA,  roUNO  IS  SET  TO  TRUE  IF  AN  INSTANCE 
SATISFYING  THE  SELECTION  CRITERION  IS  LOCATED, 
OTHERWISE,  FOUNO  IS  ASSIGNED  THE  VAlUE  FALSE,  *>, 
LOCALITY!  GLOBAL. 
typei  boolean, 

USE!  BOTH, 
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TLS  KERNEL 


IRXCSOIIO  P*» 


R.NET  :  CC.PESPONSE. 

STRUCTURE: 

INPUT. INTERFACE  .  CC.IN 

ALPHA  :  VALIOATE.HEAOER 

00 

ALPHA  :  ACKNOWLEDGE 
OUTPUT.INTERFACE  :  CC.OUT 

ANO 

CONSIDER  OATA  :  COMMAND.ID 
00 

(HANDOVER. IMAGE) 

ALPHA  :  TRACK.INITIATE 
EVENT  :  ALLOCATE 
OUTPUT.INTERFACE  :  DAT A.RECORO 
OR 

(DROP.TRACK) 

ALPHA  :  TERM.TRACK 
OUTPUT.INTERFACE  :  DATA.RECORO 

OR 

(INITIATE.ENGAGEMENT.HODE) 
ALPHA  S  STARTER 
ALPHA  5  ENGAGEMENT.INITIATION 
EVENT  :  SCHEOULE 
EVENT  :  SUMMARIZE 
TERMINATE 
OR 

(TERMINATE.ENGAGEMENT.MODE) 
ALPHA  :  TERM.ENGAGEMENT 
TERMINATE 
OTHERWISE 

ALP**  :  rc.ERROR.PROCESSING 
TERMINATE 

END 

END 
END  . 


R  NET  S  CONTROL .RESOURCES* 

STRUCTURE: 

ALPHA  :  ALLOCATE.ANO.CONTROI _ RESOURCES 

TERMINATE 
END  . 


R  NET  J  RADAR.SUMMARY. 

STRUCTURE: 

CONSIDER  OATA  :  MODE 
00 

(ENGAGED) 

FOR  EACH  ENT ITY.TYPE  :  RE TURNED .PULSE 
00  ALPHA  :  SUMMAR IZE.USAGE  ENO 

ALPHA  :  COMPLETE.SUMMARY 
EVENT  :  SUMMARIZE 
OUTPUT.INTERFACE  :  OATA.RECORO 
OTHERWISE 
TERMINATE 

END 
END  . 
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R  NET  :  RADAR_TIMING. 

structure: 

INPUT_INTERFACE  :  RADAR..CLCCK.I  N 
alpha”:  upoate_raoar_clock 
terminate 
END  . 


I 


R_NET  :  RESPONSE _TO_RADAR. 

structure: 

INPUT.INTERFACE  ;  RAOAR_IN 

ALPHA  :  ACCEPT_AN0_CHECK_RADAR_3ETURN_MESSAGE 
CONSIDER  DATA  :  R£TURN_I MAGE_S T AT US 
00 

(IN.TRACK) 

CONSIDER  DATA  :  RADAR_T YPE 
DO 

(T3> 

OTHERWISE 

ALPHA  :  TI_T2_MEASUREMENT_EXTRACTI0N 

END 
•  00 

(VALID.RETURN) 

ALPHA  :  UPDATE.STATE 
00 

OUTPUT.INTERFACE  :  DATA_RECORD 

AND 

ALPHA  !  REDUN.DETERMINATION 
DO 

creoundant_image> 

ALPHA  :  REOUN_TERMlNATION 
EVENT  :  ALLOCATE 
OUTPUT.INTERFACE  :  DATA_RECORD 
OTHERWISE 
TERMINATE 

END 

AND 

ALPHA  :  LOW.ELEVATION.DETERMINATION 
DO 

(LOW_ELEVAT I ON) 

ALPHA  :  low_termination 

EVENT  :  ALLOCATE 
OUTPUT_INTERF ACE  :  0ATA_REC0R0 
OTHERWISE 
TERMINATE 

END 

END 

OTHERWISE 

ALPHA  :  GHOST.OETERMINATION 
00 

(GHOST.IMAGE) 

ALPHA  :  GHOST_TFRMINATION 
EVENT  :  ALLOCATE 
OUTPUT_!NTERFACE  :  DATA.RECORD 
OTHERWISE 
TERMINATE 

END 

END 

OR 

(DROPPEDI 

TERMINATE 

OTHERWISE 

ALPHA  :  RR.ERROR  PROCESSING 
TERMINATE 

END 
END  . 
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P.NET  :  SKED  R. 

structure: 

CONSIDER  OATA  :  MODE 
DO 


(ENGAGED) 

ALPHA  :  INITIALIZE  SKED  R 

™  eniity.t7pe  :'im*ge_in_track 

(LAST.PULSE* (1, 0/TRACK _R ATE) <  TEOF) 

“r«ch  ?afH*=!c:^0ir,D4TESEN° 

EVENT  :  xr|U8NET  ‘  Fa**-F*'*F  E"0 
TERMINATE 
OTHERWISE 
TERMINATE 

END 


SUCH 


Th*t 


END 


R.NET  :  XMIT_R. 

STRUCTURES 

ALPHA  :  PICK_COMMANO 
DO 

(FOUND) 

EVENT  :  XR9 

CONSIDER  DATA  i  RADAR  TYPE 
DO 

(T3) 

ALPHA  :  FORM  T3 
OTHERWISE 

ALPHA  :  FORM_TI  T2 

END 

OUTPUT.INTERFACE  :  RADAR  OUT 
OTHERWISE 

EVENT  :  SCHEOULE 
TERMINATE 

END 
END  . 
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SUHNFT  :  FOKMJ-^WF. . 

STRUCT JHt  : 

ALPHA  :  »•  INU.LOi'lt-LIC  I 
IJ<> 

<  i  K)  T  uH0F_r  L  Ao) 
al-'ha  :  >iam:  ..Cu^haism.) 
•)T  >-ttH  *>  i  bt" 

►.  (VJI) 

Kh  TUHM 
tNU  . 


entity-class  :  image 
associates 

OATA  :  ENTRY-TIME 
DATA  :  IMAGE'lO 
COMPOSED 

ENTITY-TYPE  :  DROPPED  IMAGE 

associates  ~ 

FILE  :  TERMINATOR 

contains 

data  :  oroP-Reason 
Ent r tv  rvor  0ATA  :  DROP-TIME 

data  :  COVARIANCE 


DATA 

DATA 

DATA 

DATA 


LAST-PULSE 

STATE 

TRACK-RATE 

WAVEFORM 


ENTITY-CLASS  :  PULSE 
ASSOCIATES 

DATA  :  PULSE  10 

data  :  pulseItype 

DATA  :  TAPGET  ID 

DATA  :  xmit_s?art 
COMPOSED 

ENTITY_TYPE  :  LOST  PULSE 
ASSOCIATES 

DATA  :  accounteo  FOR 

ENTITY_TYPE  j  RETURNED  PULSE 
ASSOCIATES  " 

_  •  0ATA  :  ACCOUNTED  for 

ENTITY-TYPE  :  T1  T2  PULSE 
ASSOCIATES 

DATA  :  RECEIVE  STOP 
DATA  :  T1-T2-XMIT 
ASSOCIATES 

FILE  : *Tl-[ 2-WINDOW 
CONTAINS 

entity.type  ?‘tT3*  pulTseT:>-WIND0W-0*T‘ 
associates 


OATA  :  RECEIVE  STOP 
DATA  :  T3-XMIT 
ASSOCIATES 

FILE  :  T3-WIN00W 
CONTAINS 

OATA  S  t3-MIND0M-DATA 
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InPUT_INTERFACE  :  CC_IN 
PASSES 

MESSAGE  :  HANDOVER 
MADE 

DATA  :  COMMANDED 
DATA  :  HO_ID 

DATA  :  INITIAL _COV ARIA NCE 

DATA  :  INI  T I A1 _ STATE 

MESSAGE  :  MODE_CHANGE 

MADE 

DATA  :  COMMANO_ID 
MESSAGE  :  TERMINATION 
MADE 

DATA  :  COMMANDED 
DATA  :  HO.ID 


iNPUT_INTERF ACE  :  RADAR_CLOCK_lN 
PASSES 

MESSAGE  :  R_CLOCK_MESSAGE 
MADE 

DATA  :  RADAR_CLOCK_TIME 
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INPUT.INTERFACE  :  RAOAR.IN 
PASSES 

MESSAGE  :  T 1.T2.RETURN 
MAOE 

OATA  :  RAOAR.TYPE 
DATA  :  RR.ORDER.ID 
DATA  :  T1.T2.PECEIVE 
INCLUDES 

DATA  :  ALPHA.ERROR 
DATA  :  BETA.ERROR 
DATA  :  T1T2RTN.ERROR.REPORT 
INCLUDES 

DATA  :  RFASON.FOR.TRANSMISSION 
OATA  :  WAKE_ARRAY 
INCLUDES 

DATA  :  AVERAGE_SIGNAL_POWER 

DATA  :  THRESH  OLD  .DOWN  ..CROSSING  TI-F 

DATA  :  THRESHOLD  JJP_CROSSING_T I M£ 

MADE 

FILE  :  T1.T2.DAT  A 
CONTAINS 

DATA  :  T1.T2.RECORD 
INCLUDES 

DATA  :  NOISE.LEVEL 
DATA  S  RANGE.MARK.INFORMATION 
INCLUDES 

DATA  :  RANGE.MARK.TIME 
DATA  :  SIGNAL.AMPLITUDE 

MESSAGE  J  T3.RETURN 
MADE 

OATA  :  RAOAR_TYPE 
DATA  :  RR.ORDER.ID 
DATA  :  T3.RECEIVE 
INCLUDES 

DATA  J  ALPHA.ERROR 
DATA  :  BETA.ERROR 
DATA  J  T3RTN.ERR0R.REP0RT 
INCLUDES 

DATA  :  REASON.FOR.TRANSMISSION.FAILURE 
DATA  J  WAKE.ARRAY 
INCLUOES 

DATA  :  AVERAGE.SIGNAL.POWER 

DATA  :  THRESHOLD_DOWN.CROSSING.TIME 

DATA  :  THRESHOLD_UP.CROSSING.TIME 

MADE 

FILE  :  T3.DATA 
CONTAINS 

DATA  :  T3.REC0RD 
INCLUDES 

DATA  !  NOISE.LEVEL 
DATA  J  RANGE.MARK.INFORMATION 
INCLUDES 

DATA  :  RANGE.MAPK.TIME 
OATA  :  SIGNAL.AMPLITUDE 
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OUTPUT.INTERFACE  :  CC.OUT 
PASSES 

MESSAGE  :  ACKNOWLEDGEMENT 
MAOE 

DATA  :  COMMANDED 

OUTPUT. INTERFACE  :  DATA.RECORD 

PASSES 

MESSAGE  :  RAOAR.USAGE 
MAOE 

DATA  :  DATA.RECORD.TYPE 

DATA  :  ENGAGEMENT .TIME 

DATA  :  RESOURCES 

MESSAGE  :  ST  ATE.UPDATE 
MAOE 

DATA  :  CURRENT.STATE 

DATA  :  DATA.RECORD.TYPE 

DATA  :  HO.ID 

MESSAGE  :  TRACK.!  NIT  I AT  ION 
MADE 


I 


DATA 

DATA 

DATA 

DATA 

MESSAGE  S 
MADE 
DATA 
DATA 
DATA 
DATA 


:  DATA.RECORD.TYPE 
:  HO.ID 

:  INITIAL.STATE 
:  TIME. OF. INITIATION 
TRACK. TERM I NAT ION 

DATA.RECORD.TYPE 
HO.ID 

REASON.FOR.DROP 
TIME.OF.DROP 


OUTPUT.INTERFACE  :  RADAR.OUT 
PASSES 

MESSAGE  S  T1.T2.COMMAND 
MADE 

DATA  :  RADAR.TYPE 
DATA  :  RR.ORDER.ID 
DATA  :  TRANSMI T.START 
DATA  :  T1 .T2. TRANSMIT 
INCLUDES 

DATA  :  ALPHA.PHASE_TA?£R 
DATA  :  BETA_PHA5E_TAPER 
DATA  :  RECEIVE  INFORMATION 


INCLUDES 

DATA 

DATA 

DATA 


LF  NOTH. OF  .RECE I VE 

RFCFIVE.START.TIME 

RFCE I  VER.GAIN.SETT ING 


MADE 

FILE  :  T1.T2.GATE 
CONTAINS 

DATA  :  Tl_.T2.GATE.OAT A 
INCLUDES 

DATA  s  acceptance.threshold 


MESSAGE  : 
MADE 

DATA 
DATA 
DATA 
rut  & 


DATA 

OATA 

DATA 

OATA 

DATA 

T3.COMMAN0 


GATE.LENGTH 

GATE.START.TIME  TP,ul„0,ir 

RANGE.MARK.GENERATION.TECHNIQUE 

SIGNAI _ PROCESS I NG.MODE 

THRESHOLD. TYPE 


RADAR.TYPE 
RR.ORDER.ID 
TRANSMIT. ST ART 
tt  TRANSMIT 


INCLUDES 
DATA  : 
DATA  : 
DATA  : 


ALPHA. PHASE. T APER 
BETA  PHASE.TAPER 
receTve.information 


INCLUDES 
OATA  J 
DATA  S 
DATA  : 


LENGTH.OF.RECEIVE 

RECEIVE.START.TIME 

receiver.gain.setting 


MADE 

FILE  :  T3.GATE 
CONTAINS 

DATA  :  T3.GATE.DATA 

INCDATAS:  ACCEPTANCE.THRESHOLD 


DATA 

DATA 

DATA 

DATA 

DATA 


GATE.LENGTH 
GATE. ST  ART. TIME 

RANGE_MAR<.TECHNIQUE 

SIGN A! _ PROCESS I NG.MODE 

THRESHOLD. TYPE 
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file  :  CANDIDATE 
CONTAINS 

DATA  S  CANDIDATE_ENERGY 
DATA  :  CANDIDATE_IMAGE_ID 
DATA  :  CANDIDATE_WAV£FORM 
OATA  :  PRIORITY 

FILE  :  COMMAND 
CONTAINS 

DATA  :  COMMAND_ENERGY 
DATA  :  COMMAND.IMAGE^ID 
DATA  .*  COMMAND_WAVEFORM 
DATA  J  START_TIME 
DATA  :  WINDOW 

FILE  :  WAVEFORM_T  ABLE 
CONTAINS 

DATA  :  WF_CHARACTERISTICS 
DATA  :  WF_NAME 
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DATA  :  CLOCK_T IME 

DATA  :  DELTAT 

DATA  :  DROP_Ft_AG 

DATA  :  ELEVAT ION_LIMIT 

DATA  :  ENEPGY_BOUND 

DATA  :  FOUND 

DATA  :  FRAME.RATE 

DATA  :  GHOST.IMAGE 

DATA  :  1ST 

DATA  :  LAST.ALLOCATE 

DATA  :  LOW_ELEVATION 

DATA  :  MODE 

DATA  :  RADAR_CLO  ! 

DATA  :  RAOAR~MEASUREMENT 
DATA  :  RAOAR_MODEL_DATA 
DATA  :  REOUNDANT_IMAGE 
DATA  :  RETURN_IMAGE_STATUS 
DATA  :  RR_ORDFR_IQC~ 

DATA  :  SUMMARY_RATE 

DATA  :  TEOF 

DATA  :  VALID_RETURN 
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APPENDIX  D 

TLS  REQUIREMENTS  NETWORKS 


t 


IRECSOZNO  PASS 


m 


1  \ 

J  \ 


ICHWf 


csjm 


BRANCH  0R01NAL 
NO.  VALUE 


CCJRESPONSE 
BRANCH  LECENO 

CONDITIONAL  EXPRESSION 


1  ( HBNOOVER_!M«OE ) 

( ORCP_TR ACK ) 

(  INI  T  I  ATE_ENGAGEMENT_MOOE  ) 

I  TERM lNATE_ENGAGEriENT_ NODE  I 
OTHERWISE 


SKEO_R 

BRANCH  LEGEND 


H 


6RANCH  ORDINAL 

I,  NO.  .VALUE  CONDITIONAL  EXPRESSION 


1  (ENGAGED  I 

2  OTHERWISE 

3  (LAST_PULSEt( 1  .0/ TRACIL  RATE  )  <TEOF  ) 


H 


I' 

j 


i 


i' 


fORn_fRRf«e 


IJ 


RRGRR_SUHH 

RRY 


RE  TURrJEO_P 
ULSE 


StWAAIlf 

usscc 


COUPLE Tt_S 
UHOSRf 


E 

V  J 


SUMMARIZE 


RRQRR_SUf1NARY 
BRANCH  LEGEND 


8RANCH 

NO. 


1 

2 


ORDINAL 

VALUE  CONDITIONAL  EXPRESSION 


(ENGAGEO) 

OTHERWISE 
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ALPHA  !  accept_and_check_radar_return  message, 
beta: 

"VAR  X : REAL  t 

BEGIN  SELECT  FIRST  FROM  PULSE  SUCH  THAT 

<pulse_id=rr„order_id) ; 

IF  NOT  FOUND  THEN  RFTURN_lMAGE_STATUS:*NO  ORDER 
ELSE  IF  <RADAR_TYPEoPULSE_TYPE>  THEN 
RETURN_IMAGE_STATUS: =ARONG_ORDER 
ELSE  BEGIN  SET  RETURNED_PUl.SE I 
ACCOUNTED_FOR:=NEITHER{ 

SELECT  FIRST  FROM  IMAGE_IN_TRACK 
SUCH  THAT  < IMAGE_ID=TARGET_ID> I 

IF  NOT  FOUND  THEN  RE TURN_IMAGE_STATUS : ^DROPPED 
ELSE  BEGIN  RETURN_IMAG£_STATUS:«IN  TRACKT 
X*=RFCEIVE_ST0P| 

FOR  EACH  PULSE  SUCH  THAT 
(RECE I VE_STOP<K  AND  CPULS£_T YPE=T1  OR 
PULSE_TYPE=T?  OR  PULSE_TYPEsT3))  DO 
SET  LOST.PULSEl 
ACCOUNTED  _FOR::=NEITHERI 
ENDFOREACH 

ENO 

END 

END I ", 

INPUTS: 

DATA!  IMAGE.ID 
DATA:  PULSE.ID 
data:  PULSE_TYPE 
DATA:  PADAR_TYPE 
DATA:  DECEIVE.STOP 
DATA:  PR_ORDER  10 
DATA:  TARGETED. 

OUTPUTS: 

DATA:  RETURN.IMAGE  STATUS, 

SETS: 

ENTITY_TYPE:  LOST_PULSE 
FNTITY_TYPE:  RETURNED  PULSE, 

EQUATED  TO: 

SYNONYM: . CKRADMES, 

REFERRED-  flY; 

R-NET  :  RESPONSE.TO.RADAR, 


ALPHA  :  ACKNOWLEDGE. 

beta: 

"BEGIN 

end,,,/0""  ACKNOWLEDGEMENT 
FORMS: 

REFERREO^rP  *CKN0“<-EDGEHENT. 

JrJJJJ  :  CC.RESPONSE, 

ORlGiNATiNGRREOUIREMFwr-NSE~ALLOCATlON 
“"{^{^tingIrequiremen,;  dpspr'3'H-®-perf0rm*n« 

»eFEPp0ER^^fTING-RE0U,R£HENF!  D^±^ZcXAZ'i 

R-NET  !  CONTROL.RESOURCES. 
4LPH4eET»G'ERR0R'PR0CESS,NG* 

"begin 

END I " . 

REFERRED  by: 

R-NET  :  CC^RESPONSE. 


ALPHA  :  ALLOCATE.AND.CONTROl _ RESOURCES* 

BETA* 


"VAR  E .PWR.DELTA.TIME: REAL  I J: INTEGER  I 
BEGIN 
E:*O.OI 

FOR  EACH  RETURNED_PULSE  DO 

IF  ACCOUNTED  FOR=SUMMED  THEN 
BEGIN 

SELECT  FIRST  FROM  WAVEFORM.TABLE  SUCH  THAT 
( WF  NAME=PULSE.TYPE) I 
IF  FOUND  THEN  E : =£*WF.CHARAC TERISTICS* 

DESTROY  PULSE  I 
END 

ELSE  IF  ACCOUNTED.FOR*  NEITHER  THEN 
BEGIN 

SELECT  FIRST  FROM  WAVEFORM.TABLE  SUCH  THAT 
(WF_NAME=PULSE„TYPE) I 
IF  FOUND  THEN  E : =  E»WF .CHARACTERISTICS! 
ACCOUNTED.FOR :=COUNTED I 

END! 

ENOFOREACHI 

FOR  EACH  LOST.PULSE  DO 

SELECT  FIRST  FROM  WAVEFORM.TABLE  SUCH  THAT 
(WF_NAME=PULSE_TYPE) I 
IF  FOUND  THEN  E :  =E»WF.CHARACTERISTICSI 
DESTROY  PULSE  I 
ENOFOREACHI 

DELT A.T IME : *CLOCK.TIME-LAST.ALLOCATEI 

LAST_ALLOCATE:=CLOCK.TIMEI 

IF  £>0.0  THEN 

BEGIN 

PWR:=E/OELTA.TIMEl 
j:  *01 

FOR  EACH  IMAGE.IN.TRACK  DO  U:  =J* 1 1 ENOFOREACHI 
FOR  EACH  IMAGE.IN.TRACK  DO 

SELECT  FIRST  FROM  WAVEFORM.! ABLE  SUCH  THAT 
(WF_NAME*WAVEFORM) | 

IF  FOUND  THEN  TRACK.RATE : * ( PWR/J) /WF. CHARACTER I ST ICS I 
ENOFOREACHI 
END 
ENOI " • 

OESTROYS* 

ENTITY.CLASSS  PULSE. 

INPUTS: 

DATA:  ACCOUNTEDlFOR 
data:  CLOCK.TIME 
DATA:  IMAGE_ID 

data:  last.allocate 
data:  pulse.type 

data:  WAVEFORM 
FILE:  WAVEFORM.TABLE. 

OUTPUTS: 

data:  accounted.for 
data:  last.allocate 
data:  TRACK.RATE. 

TRACED  FROM: 
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ALPHA  :  COMPLETE_SUMMARY. 

BETAS 

"BEGIN  FORM  RADAR_USAGE I 

DATA.RECORD.TYPE  :  =R  AD  AR_US  AGE  ..REPORT  I 

engagement_time:=clock_time 

End i " • 

FORMS  S 

MESSAGE:  RADAR.USAGE, 

INPUTS: 

OATA:  CLOCK.TIME, 

OUTPUTS: 

DATA:  data_rfcord.type 
data:  ENGAGEMENT.TIME, 

REFFRRED  BY: 

R_NET  :  RADAR.SUMMARY, 

ALPHA  :  ENGAGEMENT.INITIATION. 

BETA: 

"CONST  X=ENGAGED» 

BEGIN  MOOES=X 
END  I " • 

OUTPUTS* 

DATA:  MOOE. 

REFERRED  BY: 

R.NET  :  CC_ RESPONSE* 

ALPHA  :  FINO— CONFLICT • 

BETA: 

"BEGIN 

OkuP_FLAG  S  *falsei 
FOR  EACH  COMMAND  DO 

IF  START„TlME>TEOF  THEN  BEGIN 
DROP_FLAG:=TRUEI 
DESTROY  CANDIDATE  END I 

ENOFOREACHI 

ENDI". 

DESCRIPTIONS 

"COMPARES  TRANSMIT  RFCEIVE  WINDOW  OF  THE  CANDIDATE  *ITM 
THOSE  OF  THE  THEN_CURRENT  COMMAND. FOR  CONFLICT,  IF 
A  CONFLICT  IS  FOUND  DROP.FLAG  IS  SET  TRUE,", 

inputs: 

data:  start.time 
data:  TEOF. 
outputs: 

data:  DROP.FLAG, 

TRACED  FROM: 

decision:  track_performance_allocation 
originating.reouirement:  DPSPR_3_?J?.B_PERF0RMANCE 
0RI3INATING.RE0UIREMENT:  DPSPR«3_2_3_E_FUNCU0NAL» 
REFERRED  by: 

SUBNET  :  FORM^FRAME, 
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ALPHA  :  FORM  T 1  T2. 

BETA: 

"BEGIN 

FORM  T1_T2_C0MMAND« 

T1_T2_TRANSmit:=o.o« 

CREATE  T1_T2_GATEI 
* '-^2_GATE_0ATA :  =o .  0 1 
SET  T1_T2_PUISE| 

RECElVE_STOP:=START  TIMEI 
T1_T2_XMIT:=o.O|  " 

CREATE  T1_T2_WIND0W I 

T1_T2_¥INOOW_OATA:bO.OI 

ENDJm. 

FORMS! 

inputs:SSAGE'  Ti-2-c°hhano. 

FILE:  COMMAND. 

OUTPUTS: 

data:  peceive_stop 
data:  Tl_T2_TRANSMIT 
data:  Tl_T2_XMIT 
file:  T1_T2J3aTE 
setsfiLF:  Tl_T2_tf INOOW . 

ENTITY.TYPE:  T1_T2_PULSE* 
traced  FROM: 

ORIGINATING.REQUIREMENT:  DPSPR3  2  ?  r  rUKirrmw*! 

rEfEBsg^,,no-re°uiremeni:  ^idiyssTi'sst: 

R,NET  :  XMIT^R. 

alpha  :  FORM  T3. 

BETA: 

"BEGIN 

FORM  T3.COMMANOJ 
T3_TRANSMIT:=0.0I 
CREATE  T3J5ATEI 

T3_GATE_DATA:=0.0I 

SET  T3.PULSEI 
T3_XMIT:=O.OI 
RECEIVE _$TOP:*START  TIMEI 
CREATE  T3_WtNOOrfl 

T3_window_data:=o.oi 

ENDI". 

FORMS: 

MESSAGE:  T3„C0MMAND. 

INPUTS: 

FILE!  COMMAND. 

OUTPUTS: 

data:  RECEI VE_STOP 
data:  T3_TRANSMIT 
data:  T3_XMIT 
FILE:  T3JSATE 
FILE:  T3.WINDOW. 

SETS: 

ENTITY.TYPE:  T3.PULSE. 
traced  from: 

ORIGINATING_REOUIREMENT:  DPSPR  1  ?_?  r  functtomai 

»EEEB^,,N6-"EOU"<t'"ENT'  °«'«±’±E:™c"'S™!:. 

R.NET  :  XMIT.R. 


ALPHA  :  GHOST.DETERMINATION. 

BETAS 

"BEGIN  GHOST.IMAGE:=  <RADAP_MEASUREMENT>*10.0)  ENDI". 

inputs: 

data:  raoar.measurement. 

OUTPUTS: 

data:  ghost. image. 

TRACED  FROM: 

decision:  track.performance.allocation 

ORIGINATING.REOUIREMENT:  DPSPR.3.?.?.R_FUNCT IONaL 
originating.reguirement:  DPSPR.3.P.2.B.PERF0RMANCC 
ORIGINATING.REGUIREMENT:  DPSPR.3.?.3.C_FUNCT IONAL. 
REFERRED  BY: 

R.NET  :  RESPONSE.TO.RADAR. 

ALPHA  :  GHOST  .TERM I NAT I ON. 

BETA: 

"BEGIN  SET  DROPPED. I MAGE  I 

FORM  TRACK. TERMINATION I 
CREATE  TERMINATOR! 

HO.ID: =IMAGE.IO! 

REASON.FOR.OROP : sGHOST I 
DROP.REASON:aGHOSTl 
TIME  OF_DRUP:=CLOCK.TIMEt 
DATA_REC0RD.TYFE:=TRACK.TERMINATI0N_REP0RT| 

drop.time:=clock.time 

ENDI". 

FORMS i 

MESSAGE:  TRACK.TERMINATION. 

tmoijTS  : 

DATA:  CLOCK.TIME 

data:  image.io. 
outputs: 

data:  data.record.type 

data:  HO.ID 
data:  reason.for.orop 
data:  TIME.OF.OROP 
FILE*.  TERMINATOR. 

SETS: 

ENTITY.TYPE:  DROPPED. IMAGE. 

TRACED  FROM: 

ORIGINATING_R£QUIREMENT:  DPSPR.3.P.P.B.FUNCTI0NAL* 
REFERRED  BY: 

R.NET  :  RESPONSE.TO.RADAR. 


ALPHA  !  INITIALIZE.SKED..R. 

BETA: 

“BEGIN 

TEOF:=CLOCK_TlME*FRAME_RATEl  1ST : =CL0CK_TIMEI 
CNO»». 

DESCRIPTION: 

"COMPUTES  THE  TIME  OF  THE  END  OF  THE  CURRENT  FRAME.". 

INPUTS: 

DATA:  clockjtime 
OATA:  frame.rate. 
outputs: 

data:  1ST 
DATA:  TEOF. 

REFERRED  BY: 

R_.NET  :  SKED.R* 

ALPHA  :  LOW_ELEVATION_0£T£RMINATION. 

BETA: 

"BEGIN  LOA_ELEVATION:=(ENTRY_TIME«CLOCK_TIME>ELEWATION.LIMIT> 
ENDt". 
inputs: 

data:  current_state 
data:  elevation.limit. 
outputs: 

oata:  low_elevation. 

TRACED  FROM: 

originating.requirement:  dpspr_3_?j»_d_functional.- 

REFERRED  BY: 

R_NET  :  RESPONSE.TO.RAOAR. 

ALPHA  :  LOW.TERMINATION, 

BETA: 

"BEGIN  SET  DROPPED.IMAGEI 

PORM  TRATK^ TERMINATION! 

CREATE  TERMiNATORI 
HO_lO: =IMAGE_IOI 

reason_for_ohop:*lowi 

OROP_REASON:=LO«l 

TIME_OF_DROP:=CLOCK_TIME! 

DATA_RECOHD_TYPE:=TRACK_TERMINATION_REPORT! 

OROP.T IME : =CLOCK _T IME 

END!". 

forms: 

MESSAGE!  TRACK.TERMINATION. 

INPUTS: 

DATA:  CLOCK.TIME 
DATA:  IMAGE. ID* 

OUTPUTS: 

DATA:  DATA.RECORD.TYPE 
data:  ho.IO 
oata:  reason.for.orop 
oata:  time.of.drop 
file:  terminator. 

sets: 

entity.type:  dropped.image. 

TRACED  FROM! 

ORIGINATING.REQUIREMENT:  DPSPR„3.2_2_D_FUNCTI0NAL. 
REFERRED  BY! 

R.NET  :  RESPONSE.TO.RAOAR, 
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ALPHA  :  HAKE .COMMAND* 

BETA: 

■BEGIN 

CREATE  COMMAND I 

command_image_id:=candidate_image..io» 
COMMANoIwAVEFORM:=CAND I DATE. WAVEFORM I 

command”energy : *cano idate_ energy  I 
start„tTme:=isti 

SELECT  FIRST  FROM  IMAGE.IN.TRACK  SUCH  THAT 

( IMAGt_IO=CANDIDATE_IMAG£_IO) I 
LAST.PULSE : =START_TIME I 
OESTROY  CANDIDATE 
END I " • 

inputs: 

data:  CANDIOATE_ENERGV 
data:  canoidate.image.id 
data:  candidate.waveform 
data:  deltat 
data:  image.id 
data:  1ST. 

OUTPUTS: 

data:  command.energy 
data:  command.image.id 
data:  commandj*aveform 
data:  1ST 
data:  last.pulse 
data:  START-_TIMr. 
referred  by: 

SUBNET  ?  FOBM— FRAME , 


♦ 
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AlPWA  :  PICK.CANDIDATES. 

SETA: 

'  "BEGIN 

CREATE  CANDIDATE! 

CAH^nAIE_IMAGE_in:  =  IMA6E_I0l 
IF  WAVEFORM=Tl  THEN  PR  I  OR ITY : *1 .0 

ELSE  IE  WAVEFORM=T2  THEN  PRI0RITY:s2.0 
ELSE  PRI0RITY:=3.0I 
CANDIOATE„WAVEFORM:=WAVEFORMl 
SELECT  FIRST  FROM  WAVEFORM_T ABLE 
SUCH  THAT  WF.NAME=WAVEFORMI 
IF  NOT  FOUND  THEN  C AND I D ATE.ENERGY : =0 . 0 

ELSE  canoidate_energy:=wf_characteristicsi 
ENDS1'. 

DESCRIPTION: 

"EACH  IMAGE.IN.TRACK  WHICH  MIGHT  GENERATE  A  MESSAGE  THIS 
FRAME  HAS  ITS  T  iNSMIT  AND  RECEIVE  START  AND  STOP  TIMES 
EXTRACTED*  ITS  ENERGY  DEMAND  DETERMINED  AND  ITS 
PRIORITY  ESTABLISHED."* 

INPUTS: 

DATA:  IMAGE. ID 

data:  waveform 

(•INSTANCES  OF  ENTITY.TYPE  IMAGE.IN.TRACK*) 

file:  waveform.table* 
outputs: 

DATA:  candidate.energy 
data:  CANDIDATE. IMAGE.ID 
OAT*:  CANDIDATE.WAVEFORM 

data:  priority. 

TRACED  F3 0**: 

DECISION?  SYNCHRONOUS.VS.ASYNCHRONOUS.TRACK* 

REFERRED  BY: 

R.NET  :  SKED.R. 


ALPHA  :  PICK_COMMAND. 

BETA: 

"BEGIN 

SELECT  FIRST  FROM  COMMANOI 
IF  FOUND  THEN 
BEGIN 

TRANSMIT_START:=START_TlMEf 

radap_type:*command_waveformi 

RR_OPDER_IOC:=RR_ORDER_IDC*ll  RR_ORDER_ID:*RR_ORDER_IOCl 
CREATE  PULSE  I 

pulse_type:=command_waveform» 

target„id:=commano_image_io» 

pulse_id:=rr_order_idci 

XMIT.START:=START_TIHE| 

DESTROY  COMMANOI 
END 
END  I " • 

DESCRIPTION: 

"PICK.COMMANO  SELECTS  NEXT  COMMAND.". 

CREATES: 

ENTITY_CLASS:  PULSE. 

INPUTS: 

DATA:  RR_OROER_IOC 
data:  START.TIME 
file:  COMMANO. 

OUTPUTS: 

data:  founo 
oata:  pulse.id 
data:  pulse.type 
data:  padarjtype 
data:  pr,order_io 
data:  pr_order_ioc 
data:  targeted 
oata:  transmit_start 
data:  xmit.start. 

REFERRED  BY: 

R_NET  :  XMITJI. 


ALPHA  :  REDUN_DETERMlNATION* 

beta: 

"VA»  X: INTEGER! 

BEGIN  X:=OI 

FOR  EACH  IMAGE_IN_TRACK  00 

IF  STATE=CURHENT_STATE  THEN  X:=X»l! 

ENOFOREACHI 

SELECT  FIRST  FROM  IMAGE_IN_TRACK  SUCH  THAT 
IMAGE_ID=TARGET_IDI 
REDUN0ANT_IMAGE:=(X>1) 

END!". 

INPUTS! 

OATA:  CURRENT.STATE 
data:  STATE. 
outputs: 

data:  pedundant_image. 
traced  from: 

decision:  track_performance_allocation 
originating.reguirement:  DPSPPO..?.J?_A_FUNCTI0NAL 
originating.reguirement:  dpspr.i.?_?_b.performance 
originating_pfquirement:  DPSPR_3_?_3_9_FUNCTI0NAL. 
REFERPED  BY: 

R_NET  :  RESPONSE_TO_RADAR. 

ALPHA  :  REDUN  TERMINATION. 

BETA: 

"BEGIN  SET  DROPPEO.IMAGEI 

FORM  TPACK_TERMlNATION! 

CREATE  TERMINATOR! 

MU_iO:=lMAGE_IO! 

REASON_FOR_DROP : ^REDUNDANT! 

DROP_REASON:=  REDUNDANT! 

T I ME„OF_OPOP ! sCLOCK.T IME ! 
data_record_type:=track_termination_reporti 
OROP„TIME:=CLOCK„TIME 

END* ". 

FORMS* 

MESSAGE:  TRACK.TERMINATION. 

INPUTS* 

DATA:  CLOCK.TIME 
DATA*  IMAGE_ID. 

outputs: 

data:  data_recoro_type 
data:  ho.id 
data:  reason_for_drop 
data:  time_ofj>rop 
file:  terminator. 

sets: 

entity.type:  dropped.image. 
traced  from: 

ORIGINATING.REOUIREMENT:  0PSPR_3_2_2..A..FUNCTI0NAL* 
REFERREO  BY: 

R_NET  *  RESPONSE_TO_RADAR. 
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ALPHA  :  RR_ERROR_PROCESSING. 

ocT a;  "BEGIN  ENDI". 

REFERRED  BY! 

R^NET  !  RESPONSE„TO_RADAR. 

ALPHA  :  STARTER.  .  , 

ARTIFICIALITY!  ARTIFICIAL. 

"BEGIN  CREATE  MAVEFORM.TABLE I 
WF  NAHEisTlI 

wfIcharacteristics:*i.oi 
CREATE  WAVEFORM_T ABLE  I 
WF  NAME ! =T2 I 

WF.CHARACTERISTICS!=2.0I 
CREATE  WAVEFORM_TABLEI 
WF  NAME : =T3I 
^F  ..CHARACTER  I  ST  I  Ct.  !»3.0 

END  I ". 

DESCRIPTION!  ELEMENT  INITIALIZES  WAVEFORM.TABLE  % 

OUTPUTS! 

FILE!  WAVEF0RM_TA8L£. 

REFERRED  BY! 

r_.NET  !  CC— RESPONSE. 

ALPHA  !  SUMMARIZEJJSAGE. 

0"BEGIN  if  accounted.forosummed  then  begin 

SELECT  FIRST  FROM  MAVEFORM_T ABLE  -JCH  THAI 
(WF  name=pulse.type>» 

DPc-nilRCFs7=RES0URCES*»IF„CHARACTERISTICSl 

IF  ACCOUNT£D_FOR«COUNTEO  THEN  DESTROY  PULSE 
ELSE  ACCOUNTED_FOR -SUMMED 


END 


END I " • 

DESTROYS! 

ENTITY.CLASS!  PULSE. 

INPUTS! 

data:  ACCOUNTEO.FOR 
data:  pulsejtype 
file:  naveform.table. 

OUTPUTS! 

OATA!  ACCOUNTED.FOR 
DATA:  RESOURCES. 

Sssjssisss:  ssitajssss. 

REFERRED  BY! 

rj^ET  !  RADAR_SUMMARY . 
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alpha  *  TERM-ENGAGEMENT . 

beta: 

"CONST  Xs  STANOBY  * 
BEGIN  MOOE:*X 


eno  : "  • 

OUTPUTS: 

data:  MODE. 


REFERRED  by: 
R-NET  : 


CC-RESPONSE. 


ALPHA  *  TERM-TRACK* 

BETA: 

"const  x°cc!.comm*nd_to_oropi 
B1?UCT  f ,i,s{  hen°set  droppfd_im»se 


image-TN-Track  such 


THAT  (IMAGE.lOaHO.IOI  I 


DROPPED-IMAGE  SUCH  THAT 
GOTO  1001 


|F  FOUNO 
ELSE 

^SELECT  FIRST  FROM 
( IMAGE  IOSHO.ID) I 
IF  NOT  FOUNO  THEN 

F0rm  track-termination* 

CREATE  TERMINATOR! 

DROP  TIME:*C.L0CK.TIMEI 

D^VeC^^E :  =TR.CK_TERM.NM  ION.REPORT , 

REa5oN_FOR-DROPS*X» 

T I  Mr  OF  -DROP  :  =DR'jP„T  T  MF  » 

ENO I " • 


1001* 

forms: 

MESSAGE: 


TRACK-TERMINATION. 


INPUTS* 

data: 

data: 

OUTPUTS* 

OAT  A: 
DATA: 
DATA: 
FILE: 


CLOCK-TIME 
HO— 10. 

OATA.RECORD— TYPE 
PEASON-FOR-DROP 
TlME-OF-OROP 
TERMINATOR. 


SETSJentiTy  type*  OROPPEO-IMAGE. 

^^msssk 


OR] 


ORIGINATING-RFQUIREMENT: 

REFERRED  by: 

R-NET  * 


CC-RESPONSE. 
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ALPHA  :  TRACK _INI TI ATE. 

BETA: 

"BEGIN 

FORM  TRACK.INITIATIONI 

CREATE  IMAGE  I 

SET  IMAGE_IN_TRACK| 

T IME_OF.INI T I  AT  ION :=CLOCK_TIME I 

image_id:*ho_idi 

state:=initial_statei 

COV AR I ANCE : ^ INI T ! AL.COVAR I ANCE I 
TRACK_RATES=20.0I 

waveform:=ti i 

DATA_RECORD_TYP£:=TRACK..INITlATION.REPORTI 
ENTRY.TIME :=CLOCK_TIME 

ENDI b • 

CREATES: 

ENTITY_CLASS:  IMAGE. 

FORMS: 

MESSAGE:  TRACK.INI TIATION. 

INPUTS: 

DATA:  CLOCK.TIME 
DATA:  HO  10 

DATA:  initial.covariance 
data:  INITUl.STATE. 

OUTPUTS: 

oata:  covariance 
data:  data.recoro.type 
data:  entry.time 
data:  image.id 
data:  state 

data:  time.of.initiation 
data:  track.rate 
data:  waveform. 

SETS: 

entity.type:  i mage_in.tr ack. 

TRACED  from: 

originating.requirement:  DPSPR_3_2_1_A_FUNCTI0NAL 
ORIGINATING.REQUIREMENT:  DPSPR_T_?_S_A_FUNCTIONAL. 
REFERRED  BY: 

R.NET  :  CC— RESPONSE. 

ALPHA  :  T1_T2_MEASUREMENT_EXTRACTI0N. 

BETA: 

"BEGIN  VALID.RETURN:  si'RUEl 

RADAR.MEASUREMENT  : sTl_T2_RECEIVE 

ENDI". 

INPUTS: 

DATA:  T I _T2 .RECEIVE 
FILE:  Tl.T2.DATA, 

OUTPUTS: 

OATA:  RADAR.MEASUREMENT 
DATA:  VALID.RETURN. 

REFERRED  BY: 

R.NET  :  RESPONSE.TO.RADAR. 


ALPHA  S  T3.MEASUREMENT.EXTRACTI0N. 

beta: 

" BEGIN 

VALIO .RETURN: =000 ( TRUNC  <  T3.RECE I VE*0 . 1 ) ) * 
RADAR_HEASUREMENT:=T3.RECEIVE 

END  I " • 

INPUTS: 

DATA:  T3.RECEIVE 
FILE:  T3.0ATA. 

OUTPUTS: 

data:  RADAR.MEASUREMENT 
data:  valio.return. 

REFERRED  8Y: 

R.NET  :  RESPONSE.TO.RADAR. 

ALPHA  :  UPDATE.RAOAR.CLOCK. 

BETA: 

“BEGIN 

RADAR.CLOCK : =RA0AR.CL0CK.T I ME 
END! “ • 

inputs: 

oata:  PADAR.CLOCK.TIME. 

OUTPUTS: 

data:  radar.clock. 

REFERRED  BY: 

R_NET  :  RADAR.TIMING. 

ALPHA  :  UPDATE.STATE. 

beta: 

f BEGIN  IF  *4VEF0RN=T1  THEN  WAVEFORM ! =T?  ELSE 
IF  VAVEF0RM=T2  THEN  WAVEFORM: =T3  ELSE 
WAVEFORM:sTl I 
FORM  STATE.UPOATEI 
HO.ID:*IMAGE_IOI 
STATE:=  RAOAR.ME ASUREMENT I 
CURRENT_STATE: ESTATE » 

DAT A_REC0R0_TYPE : =  ST ATE.UPDATE.REPORT* 
COV AR I ANCE : =CLOCK .T I  ME 

END I* • 

FORMS: 

MESSAGE:  STATE_UPOATE. 

inputs: 

data:  CLOCK.TIME 
data:  IMAGE. ID 
DATA:  RADAR.HEASUREmENT 
data:  WAVEFORM. 


data: 
data: 

DATA: 

data: 

OUTPUTS: 

OATA:  COVARIANCE 
DATA:  CURRENT.STATE 
oata:  DATA.RECORD.TYPE 
data:  HO.ID 
DATA:  STATE 
data:  WAVEFORM. 

TRACED  FROM: 

DECISION:  TRACK.PERFORMANCE.ALLOCATION 
ORIGINATING.REOUIREMENT :  DPSPR .3.2.2.B.PERF0RMANCE 
ORIGINATING.REQUIREMENT:  DPSP  O_?-?_D_FUNCTl0NAL 
ORIGINATING.RF.OUIREMENT:  DP SPR.3. 2. 3.A— FUNCTIONAL* 
REFERRED  BY: 

R.NET  :  RESPONSE.TO.RADAR, 
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ALPHA  :  VAL IDATE_HEADER. 

BETA: 

"BEGIN 
END  I  ", 

INPUTS: 

data:  COMMAND  10. 

OUTPUTS: 

data:  command  id. 

TRACED  FPOMJ. 

REFER2wGB?:TIN<5-REaUIREHtNT!  °M"J-O-»-FUNCTI0N*L. 
R-NET  :  CC_RESPONSE. 


! 

| 
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DATA  :  ACCEPT ANCE_THRESHOL0. 

locality:  LOCAL. 

TYPE:  PEAL. 

USE:  GAMMA. 

INCLUDED  IN: 

DATA:  T1_T2_v>*.TE_0ATA 
DATA:  T3_GATE_0ATA. 


OATA  :  ACCOUNTED_FOR. 

RANGE  STY  6L08*L“NE  ITHER.  COUNTED.  SUMMEO'*. 
TYPE:  ENUMERATION. 

USE*.  BOTH. 

ASSOCIATED  WITH: 

ENTITY_TYPE:  LOST.PULSE 
ENTITY^. TYPE:  RETURNED .PULSE . 

INPUT alpha:  ALL0CATE.AN0_C0NTR0L_RES0URCES 

alpha:  summarizejjsage. 

OUTPUT^FROM  all0CATE^an0_C0NTR0( — RESOURCES 

alpha:  summarizejjsage. 

data  :  ALPHA.ERROR. 

locality:  LOCAL*. 

TYPE;  REAL. 

USE:  GAMMA. 

INCLUDED  IN: 

DATA:  T1_T2_RECEIVE 
data:  T3_RECETVE. 

data  :  alpha  j>hase_Taper. 

LOCALITY:  local, 
type:  REAL. 

USE:  GAMMA. 

INCLUDED  IN: 

DATA:  T1.T2.TRANSMIT 
data:  T3_TRANSMIT. 

data  :  AVERAGE_SIGNAL_POWER. 
locality:  LOCAL. 

TYPE:  REAL. 

USE:  GAMMA. 

INCLUDED  IN: 

OATA:  WAKE.ARRAY. 


f 


DATA  !  BET  A  ..ERROR, 

locality:  LOCAL. 

TYPE:  REAL. 

USE:  GAMMA. 

INCLUOEO  IN: 

DATA:  T1_T2_RECEIVE 
DATA:  T3.RECEIVE. 

D*5TA  :  0ETA„PHASE_TAPER. 
LOCALITY:  LOCAL. 

TYPE:  REAL. 

USE:  GAMMA. 

INCLUDED  IN: 

DATA:  T1_T2_TRANSMIT 
OATA:  T3.TRANSMIT. 
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OATA  :  CANOIOATE.ENERGY. 

LOCALITY:  GLOBAL. 

TYPE:  REAL. 

USE:  BOTH. 

CONTAINED  IN: 

FILE:  CANDIDATE. 

INPUT  TO: 

ALPHA:  MAKE.COMMANO, 

OUTPUT  from: 

ALPHA:  PICK. CANO I DATES. 

DATA  :  CANDlOATE_.IMAGE_.ID, 

LOCALITY:  GLOBAL. 

TYPE:  INTEGER. 

USE:  BOTH. 

CONTAINED  INI 

FILE:  CANDIDATE. 

INPUT  TO: 

ALPHA:  MAKE.COMMANO. 

OUTPUT  from: 

ALPHA:  PICK.CANDIDATES. 

DATA  :  CAND1DATE.WAVEFGRM. 

LOCALITY:  GLOBAL. 

RANGE:  "T1.T2#T3". 

TYPE:  ENUMERATION. 

USE:  BOTH. 

CONTAINED  IN: 

FILE:  CANDIDATE. 
j*jpijt  To? 

ALPHA:  MAKE. COMMAND. 

OUTPUT  FROM: 

ALPHA:  PICK.CANOIOATES. 

DATA  :  CLOCK.TIME 

(*  A  PREDEFINED  DATA  ITEM  WHICH  INCREMENTS  AT  THE 
SAME  RATE  AS  ENGAGEMENT  TIME.  EXCEPT  FOR  ITS 
INITIAL. VALUE  WHICH  IS  ARBITRARY,  CLOCK.TIME  MAY 
BE  REGARDED  AS  ENGAGEMENT  TIME.  IT  HAS  NO  CLOCK 
ERROR.  *>• 

LOCALITY:  GLOBAL. 

TYPE:  REAL. 

UNITS!  SECONDS. 

USE:  BOTH. 

INPUT  TO: 

ALPHA :  ALLOCATE.AND.CONTROL.RESOURCES 
.  alpha:  COMPLETE.SUMMARY 

alpha:  GHOST.TERMINATION 

alpha:  initialize.sked.r 
alpha:  low.termination 
alpha:  redun.termination 
alpha:  term.track 
alpha:  track.initiate 
alpha:  UPDATE^STATE^ 


OATA  r  COMMANO_EN£RGY. 

LOCALITY:  GLOBAL. 

TYPE :  REAL. 

USE:  BOTH. 

CONTAINED  IN: 

FILE:  COMMAND. 

OUTPUT  FROM: 

alpha:  MAK£_COMMAND, 

DATA  :  COMMANO_IO. 

LOCALITY:  LOCAL. 

RANGE: 

■'HAN00VER_IMAGE.DR0P_TRACK,INITIATE_ENGA6EMENT.M0DE» 

terminate_engagement_mode». 

TYPE:  ENUMERATION. 

USE:  BOTH. 

MAKES: 

MESSAGE:  ACKNOWLEDGEMENT 
MESSAGE:  HANDOVER 
MESSAGE:  MOOE_CHANGE 
MESSAGE:  TERMINATION. 

INPUT  TO: 

ALPHA:  VAL IOAT£_HEADER. 

OUTPUT  from: 

alpha:  valioate.heaoer. 

REFERRED  BY: 

R.NFT  :  CC_RESPONSE. 

DATA  :  COMmANO.ImaGE.IO. 

LOCALITY:  GLOBAL. 

TYPE:  INTEGER. 

USE:  BOTH. 

CONTAINED  INI 

FILE:  COMMAND. 

OUTPUT  FROM: 

ALPHA:  MAKE.COMMANO. 

DATA  :  COMMAND_WAVEFORM. 

LOCALITY:  GLOBAL. 

RANGE:  "T1 tT2*T3". 

TYPE:  ENUMERATION. 

USE:  BOTH. 

CONTAINED  IN: 

FILE:  COMMAND. 

OUTPUT  FROM: 

ALPHA:  MAKE .COMMAND. 

DATA  :  COVARIANCE. 

LOCALITY:  GLOBAL. 

TYPE:  REAL. 

USE:  BETA. 

ASSOCIATED  WITH: 

ENTITY.TYPE:  IMAGE.IN.TRACK. 

OUTPUT  FROM: 

ALPHA:  TRA '^..INITIATE 

alpha:  upoatc.state. 


DATA  s  CURRENT  ..STATE  • 

LOCALITY:  LOCAL, 

TYPE:  REAL. 

USE:  BETA, 

HAKES! 

MESSAGE:  STATE.UPOATE, 

INPUT  TO: 

ALPHA:  LOW_£LEVATION_DETERMlNATION 

alpha:  redun.determination. 

OUTPUT  FROM: 

ALPHA:  UPDATE.STATE. 

DATA  :  DATA_RECORD_TYPE. 

LOCALITY:  LOCAL, 

RANGE: 

" RADAR _USAGE_REPGRT,STATE_UPDATE_REP0RT* 
TRACK_TERMINATION_REPORT.TRACK_INITIATION_REPORT". 

TYPE:  ENUMERATION. 

USE:  BOTH. 

MAKES: 

MESSAGE:  RADAR.USAGE 
MESSAGE:  STATE.UPDATE 
MESSAGE:  TRACK., INITIATION 
MESSAGE:  TRACK_TERMINATION« 

OUTPUT  FROM: 

ALPHA:  COMPLETE.SUMMARY 
ALPHA:  GHOST.TERMINATION 
ALPHA:  LOW— TERMINATION 
ALPHA:  REDUN.TERMINATION 
ALPHA:  TERM_TRACK 
alpha:  TRACK.INITIATE 
alpha:  UPOATE.STATE. 

DATA  :  DELTAT. 

description: 

"MINIMUM  PULSE  SPACING  FOR  BEAM  SWITCHING. 
INITIAL.VALUE:  3.0E-6. 

LOCALITY:  LOCAL. 

TYPE:  REAL. 

USE:  BOTH. 

INPUT  TO: 

ALPHA!  MAKE.COMMAND, 

DATA  :  DROP_FLAG.. 

LOCALITY:  LOCAL. 

TYPE:  BOOLEAN. 

USE:  BOTH. 

OUTPUT  FROM: 

ALPHA:  FIND.CONFLKT. 

REFERREO  BY: 

SUBNET  :  FORM. FRAME. 


DATA 


OATA  :  DROP_REASON. 

LOCALITY:  GL08AL. 

TY?ErENUMERATION!H°ST,RE:DUN0^T,LO,',CC-COMMAND-r0-DROP“' 

USE:  BOTH. 

CONTAINED  IN: 

FILE:  terminator. 

TRACED  FROM: 

nBt?iI^I!IIG’REQUIflEHf:NT!  OPSPR.T  ?  ?  A  FUNCTIONAL 

nwTrTwJIJ^”^aUIREMENT:  DpSPR_3~;>  ?  R  FUNCTIONAL 

nRTrTNATrwr”crQlJ*REMENT:  °PSPP-'’  <’«P_0_FUNCTIONAL 
ORIGINATING_RECiUIREMENT:  DPSPR_3_?_?-F_FUNCT IONAL. 

DATA  :  DR0P_TIME. 

LOCALITY:  GLOBAL. 

TYPE:  REAL. 

USE:  ROTH. 

CONTAINED  IN? 

FILE:  TERMINATOR. 

OATA  :  ELEVATION,LIMIT. 

LOCALITY:  GL08AL. 

TYPE:  REAL. 

USE:  BOTH. 

INPUT  TO: 

ALPHA:  lo^elevation^determinatiom. 

OATA  :  ENERGY _BOUNO. 

locality:  global. 

TYPE:  opal. 

USE:  GAMMA. 

DATA  :  ENGAGEMENTS  THE. 

LOCALITY:  LOCAL. 

TYPE:  REAL. 

USE:  BOTH. 

MAKES: 

MESSAGE:  RADAR  USAGE. 

OUTPUT  FROM: 

ALPHA.*  COMPLETE.SUMMARY. 

OATA  :  ENTRYSIME, 

LOCALITY:  GLOBAL. 

TYPE:  REAL. 

USE:  BOTH. 

ASSOCIATED  WITH: 

ENTrTY_CLASSt  IMAGE. 

OUTPUT  from: 

ALPHA*  TRACK_INITIATE. 

TRACED  FROM? 

ORIGINATING.REOUIREMENT:  DPSPR_3_2-2-E-FUNCTlONAL. 


OATA 


m  -wwwiwfi  iM  miin.i^iiii 


DATA  J  FOUND 


DATA 


DATA 


DATA 


DATA 


(*  A  PREDEFINED  DATA  ITEM  WHICH  IS  SET  TO  EITHER 
TRUE  OR  FALSE  AFTER  EACH  SELECT  IN  A  BETA  OR 
GAMMA.  FOUND  IS  SET  T 0  TRUE  IF  AN  INSTANCE 
SATISFYING  THE  SELECTION  CRITERION  IS  LOCATED. 
OTHERWISE*  FOUND  IS  ASSIGNED  THE  VALUE  FALSE.  * 
LOCALITY:  GLOBAL. 

TYPE:  BOOLEAN. 

USE:  ROTH. 

OUTPUT  FROM: 

ALPHA:  PICK  ..COMMAND* 

REFERRED  BY: 

R_NET  :  XMIT.R. 

J  FRAME.RATE. 

INITIAL_VALUE:  o.oi. 
locality:  GLOBAL. 

TYPE:  REAL. 

USE:  BOTH. 

DELAYS: 

EVENT:  SCHEOULE. 

INPUT  TO: 

ALPHA:  INITIALIZE. SKED_R. 

:  GATE.LENGTH. 

LOCALITY:  LOCAL. 

TYPE:  REAL. 

USE:  GAMMA. 

INCLUDED  IN: 

DATA:  Ti.T2.GATE.0ATA 
DATA:  T3.GATE.0ATA. 

:  GATE.ST ART. TIME. 

LOCALITY:  LOCAL. 

TYPE:  REAL. 

USE:  GAMMA. 

INCLUDED  IN: 

DATA:  Tl.T2_GATE.DATA 
DATA:  T3.GATE.0ATA. 

:  GH0ST..IMAGE. 

LOCALITY:  LOCAL. 

TYPE:  BOOLEAN. 

USE:  BOTH. 

OUTPUT  FROM: 

ALPHA:  GHOST.DETERMINATION. 

TRACED  FROM: 

ORIGINATING.REQUIREMENT:  DPSPR_3.2.?_B.FUNCTI0NAL 
ORIGINATING.REQUIREMENT:  DPSPR_3_2«3_C„FUNCTI0NAL. 
REFERRED  BY: 

P.NET  :  RESPONSE.TO.RAOAR. 
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DATA  :  HO..I0. 

tOCAUT  fi  LOCAL, 

TYPE:  iNfECTR, 

USE:  BOTH. 

HAKES: 

MESSAGE:  HAVOOVEfl 
MESSAGE :  STATE  UPDATE 
MESSAGE:  TERMINATION 
MESSAGE:  TRACK. INITIATION 
MESSAGE:  TRACK  termination, 
INPUT  to: 

ALPHA:  TERM.TRACK 
alpha:  TRACK_INItIATE. 
OUTPUT  FROM: 

ALPHA:  GHOST.TERMINATION 

alpha:  low.tf.rmination  . 
alpha:  reoun.termination 
alpha:  UPDATE  STATE, 


DATA 


:  IMAGE.IO, 

locality:  global.* 

TYPE:  INTEGER. 

USE:  BOTH. 
ASSOCIATED  WITH: 

ENTITY. CLASS: 
INPUT  TO: 

alpha:  ACCEPT 
alpha:  alloca 

ALPHA:  GHOST. 


IMAGE, 


alpha: 

alpha: 

alpha: 

alpha: 

OUTPUT  FROM 

alpha: 


accept_ano_check_radar_return_message 

ALLOCATE.AND.CONTROL.RESOURCES 

ghost.termination 

LCa.TERMINATSON 

MAKE.COMMAND 

PICK.CANOIDATES 

reoun.tehmination 

UPOATE.STATE. 

TRACK.INITIATE. 


:  INITIAL_C0VARIANCE. 
locality:  LOCAL. 
type:  REAL. 

USE:  BOTH. 

makes: 

message:  HANOOVER. 

INPUT  TO: 

ALPHA:  track.initiate. 

:  INITIAL_STATE. 

LOCALITY:  LOCAL.. 

TYPE:  REAL. 

USE:  BOTH. 

MAKES: 

MESSAGE:  HANOOVER 
MESSAGE:  TRACK.INI T I AT  ION. 
INPUT  TO: 

ALPHA:  TRACK.INITIATE. 


DATA  *  1ST. 

DESCRIPTION*  "INITIAL  START  TIME  FOR  THE  FRAME.". 

locality:  LOCAL. 

TYPE:  REAL. 

USE:  ROTH. 

INPUT  TO: 

ALPHA:  MAKE.COMMANO. 

OUTPUT  FROM: 

ALPHA:  INITIALIZ£_SKED_R 
ALPHA:  MAKE. COMM AND. 


DATA  :  LAST.Al LOCATE. 

LOCALITY :  GLOBAL. 

TYPE:  REAL. 

USE:  BOTH. 

INPUT  TO: 

ALPHA:  ALLOCATE.ANO.CONTROL.RESOURCES, 
OUTPUT  FROM: 

ALPHA :  ALLOC A TE.AND_CONTROL.RE SOURCES. 


DATA  :  LAST.PULSE. 

LOCALITY:  GLOBAL. 

TYPE:  REAL. 

USE:  BOTH. 

ASSOCIATED  WITH: 

ENTITY.TYPE:  IMAGE.IN.TRACK. 

OUTPUT  from: 

alpha:  MAKE.COMMAND. 

REFERRED  BY: 

R.NET  :  SKEO.R. 

DATA  J  LENGTH_OF_RECEIVE. 

LOCALITY:  LOCAL. 

TYPE:  REAL. 

USE:  GAMMA. 

INCLUDED  IN: 

DATA:  RECEIVE.INFORMATION. 

DATA  r  LOW.ELEVATION. 

locality:  LOCAL. 
type:  BOOLEAN. 

USE :  BOTH. 

OUTPUT  FROM: 

alpha:  low.elevation.oetermination, 

.  traced  from: 

ORIGINATING.REGUIREMENT*  0PSPR_3.Z_2_C_FUNCT I ONAL • 
REFERRED  BY: 

R.NET  :  RESPONSE.TO.RADAR, 

DATA  :  MODE. 

LOCALITY:  GLOBAL. 

RANGE:  "ENGAGEO.STANOBY". 

TYPE:  ENUMERATION. 

USE:  BOTH. 

OUTPUT  FROM: 

ALPHA:  ENGAGEMENT.INITIATION 
alpha:  TEWM.ENGAGEMENT. 

REFERPED  -BY* 

R.NET  :  RADAR.SUMMARY 
R.NET  *  SKED.R, 
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DATA  :  NOISEJ.EVEL. 

LOCALITY:  LOCAL. 

TYPE:  REAL. 

USE:  GAMMA. 

INCLUDED  IN: 

DATA:  Tl_T2_REC0R0 
DATA:  T3_RECORO. 

DATA  :  PRIORITY. 

LOCALITY:  GLOBAL. 

TYPE:  REAL. 

USE:  BOTH. 

ORDERS: 

FILE:  CANDIDATE. 

FILE:  CANDIDATE. 

OUTPUT  FROM: 

alpha:  PICK„,CANDIDATES. 

TRACED  FROM: 

DECISION:  TRACK_PERFORMANCE  ALLOCATION 

OR  I G I  NAT ING.REQU IREMENT :  DPSPR _3_2_2_B_PERFORMANCE. 

DATA  :  PULSE_ID. 

LOCALITY:  GLOBAL. 

TYPE:  INTEGER. 

USE:  BOTH. 

ASSOCIATED  WITH: 

ENTITY_CLASS:  PULSE. 

INPUT  TO: 

ALPHA :  ACCEPT_AND_CHECK_RADAR_RETURN_MESSAGE. 

OUTPUT  FROM: 

ALPHA:  PICK.COMMAND. 

DATA  :  PULSE„TYPE, 

LOCALITY:  GLOBAL. 

RANGE:  "T1,T2*T3". 

TYPE:  ENUMERATION. 

USE:  ROTH. 

ASSOCIATED  WITH: 

ENTITY.CLASS:  PULSE. 

INPUT  TO: 

ALPHA :  ACCEPT_AND_CHECK_RADAR  J?ETURN_MESSAGE 
ALPHA :  ALLOCATE_AND_CONTROL_RESOURCES 
alpha:  SUMMARIZE„USAGE. 

OUTPUT  FROM: 

alpha:  PICK.COMMANO. 

DATA  :  RADAR_CLOCK. 

LOCALITY:  GLOBAL. 

TYPE:  REAL. 

USE:  BOTH. 

OUTPUT  FROM: 

ALPHA:  UPOATEJUDAR.CLOCK. 


DATA  :  RAOAR.CLOCK.TIME. 

LOCALITY:  LOCAL. 

RESOLUTION:  6.25E-9. 

TYPE:  REAL. 

UNITS:  SECONDS. 

USE:  BOTH. 

MAKES: 

MESSAGE:  R.CLOCK.MESSAGE, 

INPUT  TO: 

ALPHA:  UPDATE .RADAR. CLOCK. 

TRACED  FROM: 

ORIGINATING.REQUIREMENT:  RA0AR_DPS_IFS.3.2„9_FUNCTI0NAL, 

DATA  :  RADAR.MEASUREMENT. 

LOCALITY:  LOCAL. 

TYPE:  REAL. 

USE:  BETA. 

INPUT  TO: 

alpha:  GMOST_OETERMINATION 

alpha:  update.state, 

OUTPUT  FROM: 

alpha:  T1.T2.MEASUREMENT.EXTRACTI0N 
ALPHA :  T3_MEASUREMENT_EXTRACT I  ON. 

DATA  :  RADAR_MODEL.DAT A. 

LOCALITY:  GLOBAL. 

TYPE:  REAL. 
use:  gamma. 

DATA  :  RADAR.TYPE • 

LOCALITY!  LOCAL. 

range:  "T1.T2.T3", 

TYPE:  ENUMERATION. 

USE:  BOTH. 

hakes: 

MESSAGE:  T1.T2.CCMMAN0 
MESSAGE:  Tl.TP.P'cTURN 
MESSAGE:  T3.COMMANO 
MESSAGE:  T3.RETURN, 

INPUT  TO: 

ALPHA :  ACCEPT.ANO.CHECK.RADAR.RETURN.MESSAGE, 

OUTPUT  FROM: 

alpha:  PICK.COMMAND,  . 

REFERRED  BY: 

R.NET  :  R£SPONSE_TO.RADAR 
R_NET  :  XMIT.R, 

DATA  :  RANGE_MAHK _GENER AT ION— TECHNIQUE. 

LOCALITY:  LOCAL. 
type:  INTEGER, 

USE:  GAMMA. 

INCLUDED  IN: 

OATA:  T1.T2.GATE.DATA, 

DATA  :  RANGE.MARK.INFORMATION, 

INCLUDES: 

OATA:  RANGE.MARK.TIME 
data:  SIGNAL.AHPLITUDE, 

INCLUDED  IN:  •  - 

DATA:  T1.T2.REC0RD 
DATA:  T3.REC0RD, 


DATA  :  RANGE.MARK ^TECHNIQUE. 

locality:  LOCAL. 

TYPE:  REAL. 

USE:  GAMMA. 

INCLUDED  INS 

DATA:  T3_.GATE.DATA. 

DATA  S  RANG£_MARK_T IME • 

LOCALITY:  LOCAL. 

TYPE:  REAL. 

USE:  GAMMA. 

INCLUDED  INS 

data:  RANGE.MARK. INFORMATION. 


DATA  :  RE.ASON_FOP.OROP. 

LOCALITY:  LOCAL. 

RANGE:  "GHOST. REDUNDANT. LOM.CC.COMMAND.TO.DROP". 

TYPE:  ENUMERATION. 

USE:  BOTH. 

MAKES • 

MESSAGE:  TRACK.TERMINATION. 

OUTPUT  FROM: 

ALPHA:  ghost.termination 
ALPHA :  low.termination 
alpha:  qedun.termination 
alpha:  term.track. 

TRACED  FROM: 

originattng.reouirement:  dpspr _3_2_2_A.FUNCT i onal 
ORIGINATING  REQUIREMENT:  DrSPR.3.2_2.0.FUNCTI0NAL 
ORIGINATING  REQUIREMENT:  DPSPR JJ_2.2_0.FUNCTI0NAL 
ORIGINAT ING.REQUIREMENT :  DPSPR.3.2.2.E.FUNCTI0NAL# 

DATA  :  REASON_FOR_TRANSMISSION.FAlLURE. 

LOCALITY:  LOCAL. 

RANGE: 

"PRE.EMPTED.TRANSMISSION* 

RECE I VE. WINDOW. OVERLAP. 

TRANSMI T.W INOOW.OVERLAP. 

INS'JFFIC  IFNT.TRANSMISSION.TIME* 

RADAR.COMMAND.INCONSISTENCY* 

TRANSMIT_START.TIME.EXCEEDEO", 

TYPE:  ENUMERATION. 

INCLUDED  in: 

DATA:  T 1 T2RTN_ERR0R. REPORT 
DATA:  T3RTN.ERR0R,. REPORT . 

DATA  :  RECEIVE. INFORM AT ION. 

INCLUOES: 

DATA:  LENGTH.OF.RECEIVC 
DATA:  RECFIVE.START.TIME 
data:  recei ver.gain.settino. 

INCLUDED  IN: 

data:  T1.T2.TRANSMIT 
DATA:  T3.TRANSMIT, 
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DATA  :  RECEIV£_START_TIME. 

LOCALITY:  LOCAL. 

TYPE:  REAL. 

USE:  GAMMA, 

INCLUOEO  IN: 

oata:  receive_information. 

DATA  :  RECEIVE.STOP. 

LOCALITY:  GLOBAL. 

TYPE:  REAL. 

USE:  ROTH. 

ASSOCIATED  WITH! 

ENTITY.TYPE:  T1  T2_PULSE 
ENTITY_TYP,i:  T3_PULSE , 

INPUT  TO: 

ALPHA:  ACCEPT_AND_CHtCK_RAOAR_RETURN  MESSAGE. 

OUTPUT  FROM: 

ALPHA:  F0RM_T1_T2 
ALPHA:  F0RW„T3. 

OATA  :  RECEIVER_GAIN„SETTING. 

LOCALITY:  LOCAL- 
TYPE:  REAL. 

USE:  GAMMA. 

INCLUOEO  IN* 

DATA:  RECEIVE_lNFORMATION. 

OATA  !  REDUNDANT_!MAGE. 

LOCALITY:  LOCAL. 

TYPE:  BOOLEAN. 

USE:  BOTH. 

OUTPUT  FROM: 

alpha:  REOUN.OETERMINATION. 

TRACED  FROM! 

ORIGINATING.REOUIREMENT:  0PSPR_3_2_2_A_FUNCTI0NAL 
ORISINATING.REOUIREMENT:  OPSPR_3_2_3.B  FUNCTIONAL. 
REFERRED  8Y: 

P_NET  «  RESPONSE_TO_RAOAR. 

OATA  :  RESOURCES. 

LOCALITY:  LOCAL. 

TYPE:  REAL. 

USE:  BETA. 

MAKES: 

MESSAGE:  RADAft_U5AGE. 

OUTPUT  FROM: 

ALPHA:  summarize.usage. 

OATA  :  RETURN_IMAGE_STATUS. 

LOCALITY:  LOCAL. 

RANGE:  "IN_TRACK»OROPPED*NO_ORDER»WRONG_ORDER". 

TYPE:  ENUMERATION, 

USE:  BOTH. 

OUTPUT  FROM: 

ALPHA:  accept_and_check_radar_return_message. 

REFERRED  BY: 

R.NET  :  RESPONSE^ TO— RAOAR, 
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DATA  J  RR_OROER_IO. 

locality:  LOCAL. 
type:  integer, 
use:  both. 

HAKES: 


MESSAGE :  Tl/t2_C0MMAND 
MESSAGE :  T1.T2.RETURN 


DATA 


DATA 


t 


MESSAGE:  T 3 .COMMAND 
MESSAGE:  T3.RETURN. 

INPUT ALPHA*.  accept_and_check_radar_return.message, 
OUTPUT  FROM: 

alpha:  pick.command. 

;  RR.ORDER.IOC. 

initial.value:  0. 
locality:  global, 
type:  intesfr. 
use:  both, 
input  to: 

alpha:  pick.command. 
output  from: 

alpha:  pick.command. 

:  SIGNAt _ AMPLITUDE. 

locality:  local, 
type:  REAL. 
use:  gamma, 
included  in: 

n«T»:  pange.mahk.information* 

:  signal.processing.mode. 
locality:  local, 
type:  real, 
use:  gamma. 

included  in:  • 

0ATA:  T1.T2_GATE.DATA 
data:  T3.GATE.DATA. 


DATA  :  ST  ART.TIME • 

locality:  global. 

TYPE:  REAL. 
use:  ROTH. 

ORDERS: 

file*  commano. 

CONTAINED  IN: 

file:  command. 

INPUT  TO: 

alpha:  find.conflict 
alpha:  pick.command. 
OUTPUT  from: 

alpha:  hake .command. 


DATA 
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DATA  8  STATE. 

LOCALI T f 8  GLOBAL. 

TYPE:  REAL. 

USE!  BETA. 

ASSOCIATED  WITH: 

ENTITY.TYPE:  IMAGE„IN_TRACK. 

INPUT  TO: 

alpha:  reoun.oetermination. 

OUTPUT  FROM: 

alpha:  track.initiate 
alpha:  update.state. 

TRACEO  FROM: 

•  ORIGINAT ING.REQUIREMENT  t  DPSPR_3_2_3.A.FUNCTI0NAL. 

DATA  8  SUMMARY.RATE. 

INITIAI _ VALUE:  0.3. 

LOCALITY:  GLOBAL. 

TYPE:  REAL. 

USE:  BOTH. 

DELAYS: 

EVENT:  SUMMARIZE. 


DATA  ?  TARGETED. 

LOCALITY:  GLOBAL. 

TYPE:  INTEGER. 

USE:  BOTH. 

ASSOCIATED  WITH* 

ENTITY.CLASS:  PULSE. 

INPUT  TO: 

ALPHA 8  ACCEP7_A«D.CHECX_RADAR.RCTURN.MESS AGE. 
OUTPUT  FROM: 

alpha:  PICK.COMMAND. 

DATA  :  TEOF. 

locality:  LOCAL. 

TYPE:  REAL. 

USE:  BOTH. 

INPUT  TO: 

ALPHA:  FIND.CONFLICT. 

OUTPUT  FROM: 

ALPHA:  INITIALIZE.SKED.R, 

REFERRED  BY! 

R.NET  :  SKEO.R. 


OATA  !  THRESHOLO_OOWN.CROSSING_TIME. 
LOCALITY:  LOCAL. 

TYPE:  REAL. 

USE:  GAMMA. 

INCLUDED  IN: 

data:  VAKE.ARRAY. 


DATA  :  THRE5HOLD.TYPE. 

LOCALITY:  LOCAL. 

TYPE:  REAL. 

USE:  GAMMA. 

INCLUDED  IN! 

DATA:  T1_T2.GATE.0AT* 
DATA:  T3.GATE.OATA. 
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DATA  S  THRESHOLD_UP_CROSSING_TIME. 

locality:  LOCAL. 

TYPE:  REAL. 

USE:  GAMMA. 

INCLUDED  IN: 

data:  wake.array. 

DATA  :  T IME_OF_DROP. 

LOCALITY:  LOCAL. 

TYPE:  REAL. 

USE:  ROTH. 

MAKES: 

MESSAGE:  TRACK_TERMINAT ION. 

OUTPUT  FROM: 

ALPHA:  GHOST_TERMINATION 

ALPHA:  low_termination 
alpha:  redun.termination 
alpha:  term.track. 

DATA  :  TIME_OF_INITIATION. 

LOCALITY:  LOCAL. 

TYPE:  REAL. 

USE:  ROTH. 

MAKES: 

MESSAGE:  TRACK_INITIATION- 
OUTPUT  FROM: 

alpha:  TRACK_INITIATE. 

DATA  :  TRACK.RATE. 

<-Or.Ai.TTY:  Gl  ORAL . 

TYPE:  REAL. 

USE:  ROTH. 

ASSOCIATED  WITH: 

ENTITY.TYPE:  IMAGE_INJTRACK. 

OUTPUT  FROM: 

ALPHA :  ALLOCATE_ANO_CONTROL_RESOURCES 

ALPHA:  tpack_initiate. 

REFERREO  BY: 

R_NET  :  SKEO.R. 

DATA  :  TRANSMIT_ST ART • 

LOCALITY:  LOCAL. 

TYPE:  REAL. 

USE:  BOTH. 

MAKES: 

MESSAGE:  T1 _T2_C0MMAN0 
MESSAGE:  T3_COMMANO. 

OUTPUT  FROM: 

alpha:  PICK.COMMAND. 


OAT  A  :  T l _T2_GATE.DAT A, 

LOCALITY:  LOCAL, 

TYPE:  REAL, 

USE:  BETA, 

INCLUDES: 

DATA:  acceptance.threshold 
data:  gate.length 
data:  gate.start.time 
data:  range.mark.generation.technique 
oata:  signal.processing.mode 
oata:  threshold.type, 
contained  in: 

file:  T1.T2.GATE, 

DATA  :  T1.T2.RECEIVE, 
locality:  local, 

TYPE:  REAL, 

USE:  ROTH. 

INCLUDES: 

DATA:  ALPHA.ERROR 

data:  beta.epror  • 

DATA:  T1T2RTN.ERR0R.REP0RT 
DATA:  wake.array, 

MAKES: 

MESSAGE:  T1.T2.RETURN, 

INPUT  TO: 

ALPHA:  T1_T2_MEASUREMENT_EXTRACTI0N. 

DATA  :  T1.T2.REC0R0, 

LOCALITY:  LOCAL, 

TYPE:  REAL, 

USE:  RETA. 

INCLUDES: 

DATA:  NOISE.LEVEL 

data:  pange.mark.information, 

CONTAINED  IN: 

FILE:  T1.T2.DATA. 

DATA  :  T1.T2.TRANSMIT, 

TYPE:  REAL. 

USE:  RETA. 

INCLUDES: 

data:  alpha.phase.taper 
data:  beta.phase.taper 
data:  receive.information, 
makes: 

MESSAGE:  TI.T2.COMMANO, 

OUTPUT  from: 

alpha:  F0RM.T1.T2, 

OATA  :  T1.T2_WIND0M.DATA, 

LOCALITY:  GLOBAL* 

TYPE:  REAL. 

USE:  ROTH. 

CONTAINED  IN: 

FILE:  TI.T2.MIND0M, 
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DATA 


DATA 


DATA 


^  •  T  A 
UIA  I  « 


DATA 


:  T1.T2.XMIT. 

LOCALITY?  GLOBAL. 

TYPE:  REAL. 

USE:  ROTH. 

ASSOCIATED  WITH: 

ENTITY.TYPE:  T1.T2  PUL-$«* 

OUTPUT  FROM: 

ALPHA:  F0RM.T1.T2, 

:  T1T2RTH.ERR0R  REPORT. 

INCLUOES: 

DATA:  REASON.FOR  TRANSMESSION^H^MM*. 
INCLUOEO  IN: 

DATA:  T1.T2.RECEIVE, 

s  T3.GATE.0ATA. 

locality:  local. 

TYPE:  REAL. 

USE:  BETA. 

INCLUDES: 

DATA:  ACCEPTANCE.THRESHOLO 
data:  gate.length 
oata:  gate.start.time 
data:  range.mark.techniquc 
data:  signal.processinc.mooc 
data:  THPESHOLD.TYPE. 
contained  IN: 

file:  T3.GATE. 

:  T3.T5ECCIVE. 

locality:  local. 

TYPE:  REAL. 

USE:  ROTH. 

INCLUDES: 

DATA:  ALPHA.ERROR 

data:  beta.error 

data:  T3RTN.ERR0R.REP0RT 

DATA:  WAKE.ARRAY. 

MAKES: 

MESSAGE:  T3.RETURN. 

INPUT  TO: 

alpha:  T3.MEASUREMENT.EXTRACTI0N, 

:  T3.REC0RD. 

LOCALITY:  LOCAL. 

TYPE:  REAL. 

USE:  BETA. 

INCLUDES: 

data:  NOISE.LEVEL 

data:  range.mark.information* 

CONTAINED  IN: 

FILE:  T3.DATA. 
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DATA  :  T3.TRANSMIT. 

TYPE:  REAL. 

USE:  BETA. 

INCLUDES: 

DATA!  alpha.phase.taper 
data:  beta.phase.taper 
oata:  receive.information. 

MAKES: 

MESSAGE:  T3.CONMAND. 

OUTPUT  FROM: 

ALPHA:  FORM.T3. 

OATA  :  T3_WlNDOW_DATA. 

LOCALITY:  GLOBAL. 

TYPE:  REAL. 

USE:  BETA. 

CONTAINED  IN: 

FILE:  T3.WINDOW. 

OATA  :  T3.XMIT. 

LOCALITY:  GLOBAL. 

TYPE:  REAL. 

USE:  ROTH. 

ASSOCIATED  WITH* 

ENTITY.TYPE*  T3.PULSE. 

OUTPUT  FROM: 

ALPHA:  FGRM.T3. 

OATA  :  T3PTN_ERR0R— REPORT • 

INCLUDES: 

DATA:  REASON.FOR.TRANSMI5S10N.FAILURE. 
INCLUDED  IN: 

DATA:  T3_RECEIVE. 

DATA  :  VALID_RETURN. 

LOCALITY:  LOCAL. 

TYPE*  BOOLEAN. 

USE:  BOTH. 

OUTPUT  FROM: 

ALPHA:  T1.T2.MEASUREMENT.EXTRACTI0N 
ALPHA:  T3.MEASUREMENT.EXTRACTION, 
REFERRED  BY: 

R.NET  :  RESPONSE.TO.RADAR. 

OATA  :  WAKE.ARRAY. 

INCLUDES* 

DATA:  AVERAGE.SIGNAL.POWER 
data:  THRESHOLD_OOWN.CPOSSING.TIME 
data:  THRESHOLD.UP.CROSSING.TIME. 
INCLUDED  IN: 

DATA?  T1.T2.RECEIVE 
DATA*  T3.RECEIVE. 
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DATA  :  WAVEFORM. 

LOCALITY:  GLOBAL. 

RANGE:  "  T 1 » Tic  •  T 3 " • 

TYPE:  ENUMERATION. 

USE:  BOTH. 

ASSOCIATED  WITH: 

ENTITY.TYPE:  IMAGE.IN.TRACK. 

INPUT  TO: 

ALPHA:  ALLOCATE.AND.CONTROL.RESOURCES 
alpha:  PICK.CANDIDATES 

(♦INSTANCES  OF  ENTITY.TYPE  IMAGE. IN  Tt»AC*®> 
ALPHA:  UPDATE.ST ATE • 

OUTPUT  FROM: 

ALPHA:  TRACK. INITIATE 
ALPHA:  UPDATE.STATE. 

DATA  :  ^.CHARACTERISTICS. 

LOCALITY:  GLOBAL. 

TYPE:  REAL. 

USE:  BOTH. 

CONTAINED  IN: 

FILE:  waveform.table. 

DATA  :  WF.NAME. 

LOCALITY:  GLOBAL. 

RANGE:  "  T1*T2*T3“. 

TYPE:  ENUMERATION. 

USE:  BOTH. 

CONTAINED  IN: 

FILE:  M AVEFORM.T.AfiLE* 

DATA  £  WINDOW. 

LOCALITY:  GLOBAL. 

TYPE:  REAL. 

USE:  GAMMA. 

CONTAINED  IN: 

FILE:  COMMANO. 


DATA  :  XMIT.START • 

LOCALITY:  GLOBAL. 

TYPE:  REAL. 

USE:  BOTH. 

ASSOCIATED  WITH: 

ENTITY.CLASS:  PULSE. 
OUTPUT  from: 

ALPHA:  PICK .COMMAND. 


DECISION  i  RADAR_SCHEDULER_PRIORITIZATION. 

ALTERNATIVES: 

"l.  SCHEOULE  PULSE_BY_PULSE.  THIS  WOULD  SIMPLIFY  THE 
NETS  BUT  WOULD  OBVIATE  OPTIMIZATION; 

2.  OPTIMIZE  OVER  THE  ENTIRE  FRAME.  TAKING  THE  FRAME 
AS  A  WHOLE  GIVES  BEST  RESULTS  BUT  REQUIRES  WEIGHTING 
FACTORS  FOR  PULSE  ENSEMBLES. 

3.  PRIORITIZE  PULSFS  SUCH  THAT  ANY  PULSE  OF  HIGH 
PRIORITY  BEATS  ALL  PULSES  OF  LOWER.  THIS  IS 
SU80PTIMAL.  BUT  REALIZABLE  BOTH  IN  THE  SPEC  AND  IN 
THE  SOFTWARE  DESIGN.  NO  A  PRIORI  WEIGHTS  NEEDED.". 

CHOICE:  "OPTION  3.  PRIORITIZED  PULSES". 

PROBLEM: 

"OPTIMIZATION  OF  RADAR  USAGE  REQUIRES  A  FINITE  RADAR  FRAME. 
THIS  IMPLIES  A  PRIORITIZATION  SCHEME  FOR  INTENDED  ORDERS.". 
TRACES  TO: 

R_NET:  SKEO_R 
R_.NET :  X  M I T  _R  • 

TRACED  FROM: 

ORIGINATING.REQUIREMENT:  DPSPR_3_2„4_B_FUNCTIONAL. 

DFCISION  :  SYNCHPONOUS_VS_ASYNCHRONOUS_TRACK. 

ALTERNATIVES: 

"1.  SYNCHRONOUS  TRACKING  (OR  RESPONSIVE! 

REQUIRES  THE  LAST  RADAR  RETURN  ON 
AN  IMAGE  BE  USED  TO 
PRODUCE  THE  NEXT  RADAR 
OROER. 

2.  ASYNCHRONOUS  TRACKING  "OR  AUTOGENIC" 

ALLOWS  A  TRACK  PULSE 
TO  BE  SENT  USINGWHAT  EVER 
STATE  IS  IN  THE  DATA  BASE.". 

CHOICE: 

"ASYNCHRONOUS  TRACKING  IS 
SELECTED  TO  MAXIMIZE  THE 
ALLOWED  DP  TIME  RESPONSE 
FOR  PROCESSING  RADAR  RFTURNS. 

THIS  DOES  NOT  PROHIBIT  A  RESPONSIVE 
TRACKING  IMPLEMENTATION.". 

PROBLEM: 

"TRACKING  CAN  BE  EXPRESSED  AS 

SYNCHRONOUS  OR  ASYNCHRONOUS. 

TRACES  TO: 

AJ.PHA:  PICK.CANDIOATES. 

TRACED  FROM: 

ORIGINATING.REQUIREMENT:  DPSPR.3_2^3.A_FUNCTIONAL« 


DECISION  s  TRACK.PERFORMANCE.ALLOCATION. 

CHOICES 

■1.  ALLOCATION  WILL  BE  PERFORMED  TO  CONSTRAIN 
IMAGE  STATES  AND  RATES  AT  ALL  TIMES. 

2.  PULSE  SCHEDULING  W ILL  BE  CONSTRAINED 

8Y  a  realtionship  retween  image 
STATES.  ITS  TRACK  RATE. 

AND  THE  RADAR  CONSTRAINTS. 

3.  DEGHOSTING  WILL  BE  A  FUNCTION  OF 

RADAR  MEASUREMENTS  ONLY. 

♦  .  “UPDATE  STATE"  WILL  BE  CONSTRAINED 
BY  ITS  DIFFERENCE 
IN  BETA  AND  CEP  FROM  A 
"PERFECT  FILTER". 

5.  REDUNDANT  IMAGE  ELIMINATION 
PERFORMANCE 

WILL  BE  EXPRESSED  IN  TERMS  OF 
STATES  ONLY.". 

PROBLEM: 

"TRACK  ACCURACY  IS  A  JOINT  FUNCTION  OF 
THE  TRACK  RATE.  SUCCESSFUL  SCHEDULING* 

ACCURATE  PULSE  COWHANDS.  ANC  ACCURATE 
PROCESSING  OF  THE  RADAR  RETURN". 

TRACES  TOS 

ALPHA :  ALLOCATE.ANO^CONTROL.RESOURCES 

ALPHAS  FI NO .CONFLICT 

ALPHA:  GHOST. DETERMINATION 

ALPHA:  RFOUN.DETERMINATION 

alpha:  UPOATE.STATE 

haja:  PRIORITY, 

TRACED  FROM: 

ORIGINATING.REQUIREMENT:  dpspr.3.2_2.a. performance 
ORIGINATING.REQUIREMENT:  DPSPR.3.2_2.9_PERFORMANCE 
ORIGINATING.REQUIREMENT:  DPSPR_3.2.3_A.PERFORMANCE 
ORIGINATING.REQUIREMENT:  DPSPR.3.2.3.B.PERFORMANCE 
ORIGINATING.REQUIREMENT:  DPSPR_3_2.3.C.PERFORMANCE 
ORIGINATING.REQUIREMENT:  DPSPR_3.2_3_0_PERF0RMANCE. 
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FwTITY_CL*SS  :  IMAGE. 

ASSOC T AT ES: 

n A T a :  FNTmY_TImE 
hata:  jMAG£_in. 

COMPOSED  OF: 

PNTITY.TYPE:  f)»OPPF.O_IMAGE 
'vTIT¥_TYPE:  iwage_in_track. 

CREATED  ry: 

alpha:  TPACK_INI ri ATE. 

FmTITY.CLASS  :  PULSE. 

ASSOC  I  AT FS : 

DATA:  PULSE.ID 
data:  PULSE_TYPE 
oat  a  :  TADGET^IO 
data:  XMIT_STAHT. 

COMPOSED  OF: 

FNTTTY_TYPE:  LOSI_PULSE 
FNTITY^TYPE:  RETURNED_PULSE 
PNTITY.TYPE:  T1_T2_PULSE 
FNT I TY_TYPE :  T3_PULSE. 

CREATED  RY: 

A L P H  > •  PICK^COMMANO. 

DESTROYED  F»Y : 

ALPHA :  ALLOCATE_AND  _C0NTR0L_RES0iJRCES 
alpha:  SUMMARI ZE_USAGE. 

TRACED  FROM: 

ORIGINATING  REQUIREMENT:  DPSPRJ*_?_A_A_EUNCT I ONAL • 
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FmT1TY_TYPF  :  D^OPPfc'0_lMAGE. 

ASSOCIATES: 

FIL^:  TERMINATOR. 

COMPOSES: 

FNT I TY.CLASS:  IMAGE. 

SET  RY: 

ALPHA:  GHOST.TERMINATION 
ALPHA:  LO*_TERMINATIOn 
alpha:  REOUN_TERMlNATION 
ALPHA:  TERM_TRACK. 

ENTITY.TYPF  :  IMAGE_IN_TWACK. 

ASSOCIATES: 

data:  covariance 
oata:  last_pulse 

oata:  STATE 
oata:  TPACK_PATE 
oata:  waveform, 
composes: 

PNTITY.CLASS:  image. 

SFT  RY: 

alpha:  tpack_ini n ate. 

TRACFO  FROM: 

ORIGINATING.REOUIREMENT:  DPSPR_3_2_3_A_FUNCTIONAL. 
REFERRED  RY: 

R_NCT  :  S*E0_R. 

y 

ENTITY  TYPE  :  LOST  PULSE.. 

ASSOCIATES: 

DATA:  accounted.for. 

COMPOSES: 

c WT !TY_CLA$S :  PULSE. 

SET  RY: 

alpha:  ACCEPT_AND_CHECK_RADAR_RETJRN_MFSSAGE. 

ENTITY.TYPF  :  RETUPNED_PULSE • 

ASSOCIATES: 

DATA:  ACCOUNTED_F Ok. 

COMPOSES: 

PNTTTY^CLASS:  PULSE. 

SET  RY: 

ALPHA :  ACCEPT_AND-CHECKJ>AOARJ:*ETURN_MESSAGE. 
REFERRED  BY: 

R_NET  :  RAQAP^SUMMARY. 

FvTITY.TYPf  :  T1_T?_PULSE. 

ASSOCIATES: 

data:  PFCEIVE..STOP 
DATA:  T1_T2_XMIT 
FILE:  T 1_T2_> INDOW. 

COMPOSFS: 

PNT I TY_CL ASS :  PULSE. 

SET  «Y: 

ALPHA:  FORM_Tl_T2. 
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EVENT  :  ALLOCATE. 

ENABLES: 

R_NET:  CONTROL  .RESOURCES. 

REFERRED  BY: 

fl_NET  :  CC_RESPONSE 
P_NET  :  RESPONSE_TO_RAf)AR. 

EVENT  :  SCHEDULE. 

ENABLES: 

R_NET :  SKEO_P. 

DELAYED  BY! 

DATA:  FRAME_RATE. 

REFERRED  BY: 

R_NET  :  CC_RESPONSE 
R_NET  :  XMIT_R. 

EVENT  :  SUMMARIZE. 

ENABLES: 

R_NET:  RADAR_SUMMARY. 

DELAYED  BY: 

DATA:  SUMMARY_RATE. 

REFERRED  BY: 

R_NET  :  CC_RESPONSE 
R_NET  :  RADAR_SUMMARY. 

EVENT  :  XRB. 

DESCRIPTION: 

"TURNS  ON  R_NET  XMIT..R  FOR  THE  CURRENT  FRAME.". 
ENABLES: 

R_NET:  XMIT_R. 

REFERREO  BY: 

H_NEf  :  SKED_R 
R_.NET  J  XMIT.R, 
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FILE  :  CANDIDATE* 

CONTAINS: 

OATA:  CANDIDATE.ENERGY 

data:  candidate.image.id 
data:  candidate.waveform 
data:  priority. 

ORDERED  9Y: 

data:  priority. 

REFERRED  BY: 

R.NET  5  SKED.R, 

FILE  :  COMMAND. 

CONTAINS: 

data:  command.energy 
data:  comm and "image. id 

data:  COMMAND.WAVEFORM 
DATA:  start.time 
DATA:  window. 

INPUT  TO: 

ALPHA:  F0RM.Tl.T2 
ALPHA:  FORM.T3~" 

ALPHA:  PICK.COMMAND. 

OROERED  BY: 

DATA:  START.TIME. 

FILE  :  TERMINATOR. 

contains: 

data:  drop.reason 
data:  DROP.TIME. 
associated  with: 

ENTTTY_TYPE:  dropped  image, 
output  from: 

ALPHA:  GHOST .TERM I NAT ION 

ALPHA:  low.termimation 
alpha:  redun.termination 

ALPHA i  TERM.TRACK, 

FILE  :  T1.T2.DATA, 

contains: 

data:  T1.T2.RECORO. 

MAKES: 

MESSAGE:  T1.T2.RETURN. 

INPUT  TO: 

ALPHA:  T1.T2.MEASUREMENT.EXTR ACT I ON, 

FILE  :  T1.T2.GATE, 

CONTAINS: 

OATA:  Tl_T2.GATE.OATA. 
makes: 

MESSAGE:  Ti.T2.C0MM AND. 

OUTPUT  FROM: 

ALPHA:  F0RM.T1.T2, 
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FILE 


FILE 


FILE 
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FILE 


:  T1_T2_WIND0W. 

CONTAINS: 

OATA!  Tl_T2.WINDOW.DATA, 

ASSOCIATED  WITH: 

ENTITY.TYPE:  T1.T2.PULSE. 

OUTPUT  FROM: 

ALPHA:  F0RM.T1.T2. 

:  T3.DATA, 

CONTAINS: 

DATA:  T3.REC0RD, 

MAKES: 

MESSAGE:  T3.RETURN, 

INPUT  TO: 

ALPHA:  T3.MEASUREMENT.EXTRACTI0N, 

:  T3.GATE • 

CONTAINS: 

DATA:  T3.GATE.0ATA, 

MAKES: 

MESSAGE:  T3.C0MMAN0. 

OUTPUT  from: 

alpha:  F0RM.T3, 

:  T3.WIND0W, 

contains: 

data:  T3.WIND0W.0ATA, 
associated  with: 

ENTITY.TYPE:  T3.PULSE, 

OUTPUT  from: 

At_pMo;  F0RM.T3, 

:  WAVEFORM.TABLE, 

CONTAINS: 

OATA :  WF.CHARACTERISTICS 
data:  WF.NAME, 

INPUT  to: 

ALPHA :  allocate.and.control.resources 
alpha:  pick.canoidates 

ALPHA:  SUMMARIZE.USAGE, 

OUTPUT  FROM: 

ALPHA:  STARTER. 
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input_intf_rface  ’  cc—in. 

CONNECTS  TO*. 

subsystem:  SSC2. 

ENABLES:  r,nftuct 

R-NET:  CC_RESPONSE. 

passes”  ^wc_ 

MESSAGE:  handover 

MESSAGE:  MODE.CHANGE 

message:  termination. 

REFERRED  BY: 

R_NET  :  CC.RESPONSE. 

input  interface  :  radar.clock.in. 

CONNECTS  TO: 

subsystem:  ssraoar. 

enables:  \ 

r__net:  raoar_timing. 

P,SSEmess»ge:  r_clock_message. 

E‘PL*JeEf0erBence:  TLS_R«O.R_DPS_.NTERF.CE_SPECF.CAT.ON. 

REFET.net¥;  RAO.R_TIH.NG. 

input.interface  :  raoar.in. 

DESCRIPTION:  provides  the  MECHANISM  through 

"THE  RAOIN  INTERFACE  PROVI  ciin^YSTEM  RETURNS  IN 
WHICH  THE  OPS  RECEIVES  RA0*5ee^.rn  RY  THE  DPS  THROUGH 
RESPONSE  TO  RADAR  COM!“N?LI!m3|?stehTRETURN  MESSAGES 

THE  RAOOOT  INTERFACE.  RAOA^SUGSYSTE^RE  ^  ^  t,  # 

SHALL  COMPLY  «TH  RFOU P-  -  - p»RAGRAPH_3_2_6.  . 
RAOAR.OPS  INTERFACE^SPECIF.C^I^  3.1RT6.'. 

ENTERED_BY! 

CONNECTS  TO: 

SUBSYSTEM:  SSRAOAR. 

enarles^t  s  rESPONSE_XO_RAOAR. 

IMPLEP|rSION:  0RIGIN»L_PUBLICATI0N_DATE0_AUGUST_19TS. 

PASSES:  .  __  bctiirm 

MESSAGE:  T1.T2.RETURN 

MESSAGE:  <T3.RETURN. 

abbreviated  by: 

SYNONYM:  RAOIN. 

TLS_RAOAR_OPS_.NTERF.CE_SPEC.FICAT.ON. 

T,,‘CEn0«EG?!liT.NG_RE  .JIREMENT-  0PS»«_P»R‘GR»PH_3_E. 

referred  by:  response_toj^oar* 
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MESSAGE  :  ACKNOWLEDGEMENT. 

FORMED  BY: 

ALPHA:  ACKNOWLEDGE. 

MADE  BY: 

DATA:  COMMANDED. 

PASSED  THROUGH: 

output.interface:  CC.OUT. 

MESSAGE  :  HANDOVER. 

MADE  BY: 

data:  COMMANDED 
OATA:  HO.IO 

data:  initial.covariance 
data:  initial.state. 

PASSED  THROUGH: 

INPUT. INTERFACE:  CC.IN. 

TRACED  FROM: 

OR1GINATING.REQUIREMENT:  DPSPR J.2.1«A.EUNCTI0NAL# 

MESSAGE  :  MODE.CHANGE • 

MADE  BY: 

OATA:  COMMAND.ID. 

PASSED  THROUGH: 

INPUT. INTERFACE :  CC.IN. 

MFSSAGE  :  R.CLOCK.MESSAGE. 

MADE  BY: 

DATA:  RADAR.CLOCK.TIME. 

PASSED  through: 

INPUT. interface:  radar.clock.in. 

MESSAGE  I  PAD AH. US AGE. 

FORMED  BY'. 

ALPHA:  COMPLETE.SUMMARY. 

MADE  BY: 

DATA:  data.record.type 
data:  engagement.time 
data:  resources. 

PASSED  through: 

output. interface:  data.recoro. 

TRACED  FROM: 

originating.requirement:  DPSPR_3.2_5J>_FUNCTlONAL. 

MESSAGE  :  STATE.UPDATE. 

FORMED  BY: 

ALPHA:  UPDATE.STATE. 

MADE  BY: 

DATA:  CURRENT.STATE 
DATA:  DATA.RECORD.TYPE 
DATA:  HO.ID. 

PASSED  THROUGH: 

OUTOUT.INTERFACE:  DATA.RECORO. 

TRACED  FROM: 

ORIGINATING.REQUIREMENT:  0PSRR.3.2.5.C.FUNC T I ONAL • 
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MESSAGE  :  TERMINATION. 

MADE  8YS  „ 

data:  COMMANO.ID 
DATA:  HO.ID. 
PASSED  THROUGH: 

inpjt.interface: 
TRACED  FROM: 


* 


CC.IN. 


Srigin;tin6.requirement:  DPSPR_3_2.2_E.FUNCTI0NAL. 

MFSSAGE  :  TRACK. INITIATION. 

FORMEO  BY: 

alpha:  track.initiate. 

data:  data.record.type 
data:  HO.ID 
OATA:  INITIAI — STATE 
data:  TIME.OF.INITIATION. 

PARSED  THROUGH: 

output.interface:  data.record. 

TRACE0RIGINATING.REQUIREMENT:  DPSPRJJ.2-5-A.FUNCTI0NAL. 

MFSSAGE  S  TRACK.TERMINAT ION. 

FORMED  BY: 

alpha:  ghost.termination 
alpha:  low.termination 

ALPHA:  REDUN.TERMINATION 

alpha:  term.track. 

MADE  RY:  Tvor 

OATA:  DATA.RECORD.TYPE 

DATA:  HO.ID 

data:  REASON.FOR.DROP 

data:  TIME.OF.DROP. 

PASSFD  through:  ^ 

OUTPUT.INTERFACE:  OATA.RECORD. 

TRACED  FROM;  ormltDPMrNT •  DPSPR  3  2  5  B.FUNCTIONAL. 

ORIGINATING.REQUIREMENt.  - 

MFSSAGE  :  T1.T2.C0MMAND. 

EQUATED  to: 

SYNONYM:  T1T2CM0. 

EWL*KMi«.  TLSJUO.R_OPS_INTERFACE_SPECIFlC.nON. 

FORMEO  BY: 

ALPHA:  F0RM.T1.T2. 

MADE  BY: 

data:  RAOAR.TYPE 
DATA:  RR.OROER.ID 

data:  transmit.start 
data:  T1.T2.TRANSMIT 
FILE:  T1.T2.GATE. 

PASSEOUTPUT!!lNTERFACE:  RAOAR.OUT. 


§ 
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MFSSAGE  :  T1_T2_RETURN. 

EQUATED  TO: 

SYNONYM :  T1T2RTN. 

EXPLAINED  B fi 

REFERENCE:  tls_radarj>ps  interface.specification. 
MADE  BY: 

DATA:  RADAR.TYPE 

data:  rr_order_io 
data:  T1_T2_RECEIV£ 

FILE:  T1_T2_0ATA. 

PASSED  THROUGH: 

input_interface:  radar_in. 

MFSSAGE  :  T3_C0MMAN0. 

EQUATED  TO: 

SYNONYM:  T3CMO. 

EXPLAINED  BYS 

reference:  tls_raoar_dps_interface_specification. 
FORMED  BY: 

ALPHA:  FORM.T3. 

MADE  BY: 

data:  RAOARJTYPE 
data:  RR_ORDER_ID 
data:  transmit„start 
data:  T3_TRANSMIT 
FILE:  T3_GATE* 

PASSFO  THROUGH: 

OUTPUT_INTERFACE:  RADARJJUT, 

MFSSAGE  :  T3_PETURN. 

EQUATED  to: 

SYNONYM:  T3RTN. 

EXPLAINED  BY: 

reference:  TLS.RADAR_DPS_lNTERFACE.SPECIFICATION. 
MADE  RY: 

DATA:  RADAR_TYPE 
DATA:  RR_ORDER_IO 
DATA:  T3_RECEIVE 
FILE:  T3J5ATA. 

PASSED  THROUGH: 

INPUT  INTERFACE:  RADAR.IN. 


ORIGINATING .REQUIREMENT  :  DPSPR.PARAGR APH.3.2 . 

TRACES  TO: 

INPUT.INTERFACE:  RaDAR.IN 
OUTOUT.INTERFACE:  radar.out. 

ORIGINATING .REQUIREMENT  :  DPSPR.3.2.1.A.FUNCTIONAL. 

DESCRIPTION! 

"ACTIONS:  ACCEPT  C2  MESSAGE* INITIATE  TRACK  ON  IMAGE* 
SEND  RADAR  ORDER 

INFORMATION:  C?  MESSAGE  "INITIATE  TRACK  COMMAND"* 
HANDOVER  IMAGE*  RADAR  ORDER". 

TRACES  TO*. 

alpha:  TRACK.INITIATE 
alpha:  VALIDATE.HEADER 
MESSAGE:  HANDOVER. 

ORIGINATING.REQUIREMENT  :  DPSPR_3_2_2.A.FUNCTI0NAL. 

DESCRIPTION: 

"  ACTION:  SEND  RADAR  ORDER 

INFORMATION:  RADAR.  REDUNDANT  IMAGE.". 

TRACES  TO: 

ALPHA:  REOUN.DETERMINATION 
ALPHA:  REDUN_TERMINATION 
data:  drop.reason 
data:  REASON.FOR.OROP 
DATA:  REDUNDANT. IMAGE. 

ORIGINATING.REQUIREMENT  :  DPSPR.3.2.2.A.PERFORMANCE. 

TRACES  TO: 

OECISION:  TRACK.PEPFORMANCE.ALLOCATION, 

ORIGINATING.PEQUIREMENT  :  DPSPR.3 .2 .2.8 .FUNCTIONAL. 

DESCRIPTION: 

«  ACTIONS:  SEND  RADAR  ORDER 

INFORMATION:  GHOST  IMAGE*  RADAR  ORDER. ■. 

TRACES  TO: 

ALPHA:  GHOST.DETERM I NATION 
alpha:  GHOST.TERMINATION 
data:  DROP.REASON 
data:  GHOST.JMAGE 

oata:  peason.for.drop. 

OPIGINATING.REQUIREMENT  !  DPSPR.3.2.2.B .PERFORMANCE. 

TRACES  TO: 

ALPHA :  ALLOCATE.AND.CONTROL.RESOURCES 
ALPHA:  FIND.CONFLICT 

alpha:  ghost.determination 
alpha:  redun.determination 
alpha:  update.state 
data:  priority 

OECISION:  TRACK.PERFORMANCE.ALLOCATION. 
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ORIGINATING.REQUIREMENT  :  DPSPR_3_2  p  c  FUNCTIONAL. 

DESCRIPTION: 

*•  ACTION:  SEND  RAOAR  ORDER 

INf  ORMAT ION :  RAOAR  ORDER.  ELEVATION  OF  RADAR  OROER''. 
TRACES  TO: 

ALPHA:  F0RM_T1_T2 
ALPHA:  FORM.T3 
OATA:  LOW.ELEVATIGN. 

ORIGINATING.REQUIREMENT  :  DPSPR_3_?,2  D .FUNCTIONAL. 

DESCRIPTION: 

U  ACTION:  SEND  RADAR  ORDER.  DETERM1NE_IMAGE_ELEVATI04 
INFORMATION:  IMAGE.  ELEVATION  OF  IMAGE.  RADAR  ORO. 

TRANSMISSION  TIME  OF  RADAR  ORDER**, 

TRACES  TO: 

ALPHA:  LOW_EL E VAT ION_DE TERMINATION 
ALPHA:  LOW.Tf RMINATION  • 

ALPHA:  UPOATE.STATE 
data:  drop_reason 
data:  peason_for„orop. 


ORIGINATING.RFOUIREMENT  :  DPSPR_3_2_2_E_FUNCTI0NAL. 

description: 

«  action:  OROP  TRACK  ON  HANDOVER  IMAGE,  SEND  RADAR  OROER 
INFORMATION:  OROP  TRACK  C2  MESSAGE.  RADAR  OR 
OER.  TRANSMISSION 


TIME  OF  RADAR  ORDER.*'. 

TRACES  TO: 

alpha:  TERM .TRACK 
data:  DROP.REASON 

^  •  *r  .  ■  *"■ .  »  *  *♦•“ 

t'M  M.  LWIlM.li  '*1C 

DATA:  PEASON.FOR.OROP 
MESSAGE:  TERMINATION. 


ORIGINATING.REOUIREMENT  :  DPSPR_3_2_3_A_FUNCTIONAL. 

DESCRIPTION: 

"  ACTION:  MAINTAIN  TRACK  ON  IMAGE 

INFORMATION:  IMAGE"FSTIMATE  OF  STATE'*.  RAOAR  RETURNt 
TIME  OF  LAST  PROCESSED  RETURN. •*. 

TRACES  TO: 

ALPHA:  UPOATE.STATE 
OATA:  STATE 

DECISION:  SYNCHRONOUS_VS_ASYNCHRONOUS_TRACK 
ENTITY.TYPE:  IMAGE.IN.TRACK, 

ORIGINATING.REOUIREMENT  :  DPSPR_3_2_3_A_PERFORMANCE. 

TRACES  TO: 

decision:  track.performance.allocation, 

ORIGINATING.REOUIREMENT  :  DPSPR_3 J2.3.B.FUNCT IONAL. 

DESCRIPTION: 

ii  ACTION:  OROP  IMAGE "PEDUNDANTi* 

INFORMATION:  REDUNDANT  IMAGE. “. 

TRACES  TOI 

alpha:  reoun.oetermination 
OATAJ  REOUNDANT_IMAGE. 
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ORIGINATING.REQUIPEMENT  :  DPSPR.3_2_3.B ..PERFORMANCE. 

TRACES  TO: 

DECISION:  TRACK.PERFORMANCE.ALLOCATION# 

ORIGINATING .REQUIREMENT  :  DPSPR.3.2.3  C.FUNCTIONAL# 

DESCRIPTION: 

*  ACTION:  DROP  IMAGE "GHOST" 

INFORMATION:  GHOST  IMAGE."# 

TRACES  TO: 

ALPHA:  GHOST.OETERMINATION 
DATA:  GHOST.IMAGE# 

OPIGINATING.REQUIREMENT  :  DPSPR.3.2.3.C.PERFORMANCE. 

TRACES  TO: 

DECISION:  track.performance.allocation, 

OPIGINATING.REQUIREMENT  :  D P SPR. 3 L2-3.D. FUNCTIONAL# 

DESCRIPTION: 

"  ACTION:  SEND  RADAR  ORDER 

INFORMATION:  RADAR  ORDER* "• 

TRACES  TO: 

ALPHA :  ALLOC A TE.ANO.CONTPOL.RE SOURCES# 

ORIGINATING.REQUIREMENT  :  DPSPR.3.2.3.0 .PERFORMANCE# 

TRACES  TO: 

DECISION:  TRACK.PERFORMANCE.ALLOCA  riON. 

ORIGINATING. REQUIREMENT  :  DPSPR_3^.3.E.FUNCTIONAL# 

DESCRIPTION: 

"ACTION:  SEND  RADAR  ORDER 

INFORMATION:  RADAR  ORDER#"# 

TRACES  TO: 

alpha:  find.conflict 

ALPHA:  FORM.T1.T2 
ALPHA:  F0RM.T3# 

ORIGINATING. REQUIREMENT  :  DPSPR.3.2.4.A.FUNCTI0NAL. 

DESCRIPTION: 

"ACTION:  MAINTAIN  ESTIMATE  OF  RADAR  RESOURCES 
INFORMATION:  RADAR  RESOURCE  USAGE  ESTIMATE*  RADAR 
ENERGY  ESTIMATE*  UPPER  BOUND  ESTIMATE.". 

TRACES  TO: 

ALPHA:  summarize.usage 

ENTITY.CLASS:  PULSE. 

ORIGINATING.REQUIREMENT  DPSPR.3.2.4.B .FUNCTIONAL# 
description: 

"ACTION:  ALLOCATE  RADAR  OROERS 

INFORMATION:  RADAR  ORDERS*  IMAGE#". 

TRACES  TO: 

alpha:  ALLOCATE.ANO.CONTROL.RESOURCES 
decision:  RADAR.SCHEDULER.PRIORITIZATION 
R.NET :  CONTROL.RE SOURCES# 


E-52 


« 


ORIGINATINGJREQUIREMENT  :  DPSPR  3_?  5  A_FUNCT IONAL. 

description: 

"ACTION:  OUTPUT  TO  PERMANENT  FILE 
INFORMATION:  TIME  OF  APPEARANCE  OF  C2  MESSAGE* 

HANDOVER  IMAGE  (ESTIMATED  STATE).". 

TRACES  TO: 

ALPHA:  TRACK_INITIATE 
MESSAGE:  TRACK^ INITIATION, 


ORIGINATING^REQUIREMENT  :  DPSPR..3J?  5  B  FUNCTIONAL. 
DESCRIPTION: 

"ACTION:  OUTPUT  TO  PERMANENT  FILE 

INFORMATION:  TIME  OF  DROP  TRACK,  REASON 

DROP  TRACK.". 

TRACES  TO: 

alpha:  termjtrack 
MESSAGE:  TRACK_TERMINATLON. 


FOR 


t 

[ 


0RIGINATING_REQUIREMENT  :  DPSPR_3_2_5  C .FUNCTIONAL. 
DESCRIPTION: 

"ACTION:  OUTPUT  TO  PERMANENT  FILE,  UPDATE  STATE 
INFORMATION:  IMAGE  STATE  ESTIMATE.". 


TRACES  TO: 

MESSAGE:  STATE.UPDATE 
R_NET :  RE3PONSE_TO_RADAR. 


ORlGINATING_REOUIREMENT  :  DPSPRJ*_2_5_D_FUNCTI0NAL. 
DESCRIPTION: 

"ACTION:  OUTPUT  TO  PERMANENT  FILE 
INFORMATION:  RAOAR  RESOURCE  USAGE.". 
TRACES  TO: 

alpha:  summarize.usage 

MESSAGE:  RADAR JJSAGE 
R.NET:  RADAR.SUMMARY, 


ORIGINATING.REOUIREMENT  :  RADARJ)PS_IFS_3_2.9_FUNCTIONAL. 
TRACES  TO: 

DATA:  RAOAR_CLOCK_TIME. 
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0UTPUT_INTERF ACE  :  CC.OUT.  A 

CONNECTS  TO:  m 

SUBSYSTEM:  SSC2. 

PASSES: 

MESSAGE:  ACKNOWLEDGEMENT. 

REFERRED  BY: 

R_.NET  :  CC_RESPONSE. 

OUTPUT_INTERFACE  :  DATA.RECORD. 

CONNECTS  TO: 

subsystem:  SSPERMFL. 

PASSES: 

MESSAGE:  RADAR_USAGE 
MESSAGE:  STATE_UPDATE 
MESSAGE:  TRACK..  INITIATION 
MESSAGE:  TRACK_TERMINATION, 

REFERRED  BY: 

R_NET  :  CC_RESPONSE 
R_NET  :  RADAR_SUMMARY 
R_NET  :  RESPONSE_TO_RADAR. 

OUTPUT.INTERFACE  :  RADAR_OUT. 

DESCRIPTION: 

PTHE  RADOUT  INTERFACE  PROVIDES  THE  MECHANISM  THROUGH 
WHICH  THE  DPS  ISSUES  COMMANDS  TO  THE  RADAR  SUBSYSTEM. 

THE  RADAR  SUBSYSTEM  WILL  EXECUTE  ONLY  THE  COMMANDS  ^ 

ISSUED  BY  THE  DPS  AND  WILL  TRANSMIT  ONE  PULSE  FOR  EACH  W 
COMMAND  WHICH  SATISFIES  THE  RADAR  SUBSYSTEM  AND 
INTERFACE  CONSTRAINTS.  THE  RADAR  SUBSYSTEM  WILL  EXECUTE 
THE  COMMANDS  IN  THE  ORDER  RECEIVED  AND  WILL  BEGIN 
EXECUTION  AFTER  RECEIPT  OF  END_OF_TPANSMISSION. ■ • 
ENTERED_RY:  "H. A. HELTON,  APR.  30,  1976.", 

CONNECTS  TO: 

SUBSYSTEM:  SSRAOAR. 

IMPLEMENTS: 

VERSION:  0RIGINAL_PU8LICATI0N_DATED_AUGUST_1975. 

PASSES? 

MESSAGE:  T1_T2_C0MMAND 
MESSAGE:  T3_COMMANO. 

ABBREVIATED  BY: 

SYNONYM:  RADOUT. 

EXPLAINED  BY: 

REFERENCE:  TLS_RADARJ)PS_lNTERFACE_SPECIFICATION. 

TRACED  FROM: 

ORIGINATING.REQUIREMENT:  DPSPR  _PARAGRAPH_3_2. 

REFERRED  BY: 

R_NET  :  XMIT.R. 


R_NET  :  CC.RESPONSE. 

REFERS  TO! 

ALPHA  :  ACKNOWLEDGE 

ALPHA  :  CC.ERROR.PROCESSING 

ALPHA  :  ENGAGEMENT_INITlATION 

ALPHA  :  STARTER 

ALPHA  :  TFRM_ENGAGEMENT 

ALPHA  :  TERM.TRACK 

ALPHA  :  TRACK.INITIATE 

ALPHA  :  VALIOATE_HEADER 

OATA  :  COMMAND.ID 

EVENT  :  ALLOCATE 

FVENT  :  SCHEDULE 

EVENT  :  SUMMARIZE 

INPUT  ..INTERFACE  :  CC.IN 

OUTDUT_INTERF  ACE  :  CC.OUT 

OUTPUT.INTERFACE  :  DATA.RECORD. 

ENABLED  BY: 

INP'JT.INTERFACE*.  CC.IN. 

STRUCTURE: 

INPUT  ..INTERFACE  :  CC.IN 

ALPHA  :  VALIDATE.HEADER 

DO 

ALPHA  :  ACKNOWLEDGE 
OUTPUT.INTERFACE  :  CC.OUT 

AND 

CONSIDER  DATA  :  COMMAND.ID 
DO 

(HANDOVER.IMAGE) 

ALPHA  :  TRACK.INITIATE 
EVENT  !  Ai LOCATE 
OUTPUT. INTERFACE  :  DATA.RECORD 
OR 

(OROP.TRACK) 

ALPHA  :  TERM.TRACK 
OUTPUT. INTERFACE  :  DATA.RECORD 
OR 

( INITIATE. ENGAGEMENT. MODE) 
ALPHA  :  STARTER 
ALPHA  :  ENGAGEMENT.INITIATION 
EVENT  :  SCHEDULE 
EVENT  :  SUMMARIZE 
TERMINATE 
OR 

(TERM I NATE. ENGAGEMENT .MODE) 
ALPHA  :  TEPM.ENGAGEMENT 
TERMINATE 
OTHERWISE 

ALPHA  :  CC.ERROR.PROCESSING 
TERMINATE 

ENO 

END 
END  • 
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'NETpeSCRIPTION^ESOUHCES‘ 

IN  THEOPSPRfHREFERFNcFMINI  ™E  PEQUIREMENTS  SPECIFIED 

track  status.  ?me  eSm??v!Ji1i;age  which  REMAINS  IN 
ENVELOPES  SHALL  BE  AND  TRACK  RATE 

AND  RESOLUTION  TOLERANCE  Sufp  ir J ™IN  ACCURACY 
SPECIFIED  REQUIREMENTS  FOR  nr^rIE?T  T°  MfET  THE 
THpNlnE:RCf:PT  COITIONS.  E  TER  MI  NAT  ION  OF  TARGET 

SHALL  ALLOCATE  RESOURCES  TnF  TLS  RESo'JRCES  AND 

rr-  s»?TI«sr 

TH'Zt  SHALL  »^*nONSD"R‘°4T,ON  P°STU« 

PROFILES  and  SHALL  COMMIT  UTILIZATI0N 

REFERS  to:  ,LE  THH0U6H  ™E  "*TA  RECORD  oSt^'i^er^E?!*1 

ABBREVIATED  *BY^LOCATE'*AND”C0NTROL-RESOURCES. 

SYNONYM:  CONTRFR 
ENABLED  BY:  ES' 

traced VrR0H:ALL0C4TE* 

STRUC?2r?:IN*TIN0-',E0UIREMEnTi  0pSPR_3_S_«_8_fUNC.,  ,on<l> 

TERNI«(ATELLOC*TE'*NO-CONTROL-RESOURCES 
ENO  . 


R_NET  :  RAOAR.SUMMARY. 

REFERS  TO: 

ALPHA  :  COMPLETE.SUMMARY 
ALPHA  :  SUMMARIZEJJSAGE 
OATA  !  HOOE 

ENT  I TY_TYPE  :  RETURNED.PULSE 
EVENT  :  SUMMARIZE 
OUTPUT.INTERFACE  :  DATA.RECORD. 

ENARLEO  BY: 

EVENT:  SUMMARIZE. 

TRACED  FROM: 

ORIGINATING.REQUIREMENT:  DPSPR„3_2_5J).FUNCTIONAL. 
STRUCTURE: 

CONSIDER  DATA  :  MODE 
DO 

(ENGAGED) 

FOR  EACH  ENTITY_TYPE  :  RETURNED.PULSE 
DO  ALPHA  :  SUMMAR I ZE.USAGE  END 

AL°HA  :  COMPLETE.SUMMARY 
EVENT  :  SUMMARIZE 
OUTPUT  ..INTERFACE  DATA.RFCORD 
OTHERWISE 
TERMINATE 

ENO 
END  . 

R  NET  :  RADAR„TIMING. 

DESCRIPTION: 

"RADAR.TIMING  MAINTAINS  A  RECORD  OF  THE 
RADAR.CLOCK.TIME,". 

PEFE°S  TO* 

ALPHA  :  UPDATE.RADAR.CLOCK 
INP'JT.INTERFACE  :  RADAR.CLOCK.IN* 

ENABLED  9Y: 

INP'JT.INTERFACE :  RADAR. CLOCK. IN. 

STRUCTURE: 

INPUT. INTERFACE  :  RADAR.CLOCK.IN 
ALPHA  :  UPDATE.RADAR.CLOCK 

terminate 

END  . 


NET  :  RESPONSE .T O.R AOAR . 

DESCRIPTION: 

■TMfc  TLS.OPS  SHALL  IMPLEMENT  THE  REQUIREMENTS  SPECIFIED 
IN  THE  TLS_KADAW_0PS_INTEREACE_SPECIFICAT10N  ASSOCIATED 
WITH  PROCESSING  RADAR  SUBSYSTEM  RESPONSES  TO  COMMANDS. 
ANO  SHALL  PERFORM  THE  FUNCTIONS  HEREIN  DEFINE!)  AND 
OIAORAMMEO  IN  THE  RFSPRAI)  R.NET. 

THE  DPS  SHALL  RECEIVE  AND  PROCESS  RADAR  MESSAGES 
TRANSMITTED  BY  THE  TLS  RADAR  SUBSYSTEM  ANO  SHALL 
INTERROGATE  EACH  MESSAGE  FOR  ERRORS  AND  SHALL 
PROCESS  ALL  DETECTED  MESSAGE  ERRORS. 

THE  DPS  SHALL.  UPON  RECEIPT  OE  ERROR.EREE  RADAR 
MESSAGES,  DETECT  AND  PROCESS  REDUNDANT. I MAGES* 
GHOST.IMAGES,  AND  LOW.ELEVAT ION.IMAGES*  AND  SMALL 
UPDATE  STATE_PAPAMETERS  FOR  EACH  IMAGE.I N.TRACK . 

THE  DPS  SHALL  TERMINATE  TRACK  ON  EACH  IMAGE  WHICH  IS 
DETERMINED  TO  BE  EITHER  A  REDUNDANT  OR  GHOST  IMAGE 
OR  WHICH  IS  FOUND'  TO  EXCEED  THE  LOW.ELEVAT ION 
CONSTRAINTS  AND  SHALL  MAINTAIN  TRACK  ON  EACH  IMAGE 
DETERMINED  TO  BE  REAL. 

THE  OPS  SHALL  CONSTRUCT  AND  MAINTAIN  DESCRIPTIVE  DATA 
FILES  FOR  EACH  IMAGE  WHICH  IS  EITHER  MAINTAINED  IN 
TRACK  OR  DROPPED  FROM  TRACK  AND  SHALL  PERIODICALLY 
COMMIT  THESE  DATA  TO  PERMANENT  RECORDS  THROUGH  THE 
DATA  RECORDS  INTERFACE.". 

REFERS  TO: 

ALPHA  :  ACCEPT.ANO.CHECK.RADAR.RETURN.MESSAGE 

ALPHA  :  GHOST  .DETERMINATION 

ALPHA  :  GHOST.TERMINATION 

ALPMA  :  low.flevation.determination 

ALPHA  :  LOW.TERMINATION 

ALPHA  :  RFDUN.OETERMINATION 

ALPHA  :  PE  DUN  ..TERM  I  NAT  I  ON 

ALPHA  :  RR_ERROR_PPOCESSING 

ALPHA  :  Tl_T?_MF.ASUREMENT_EXTRACTION 

ALPHA  :  T 3.ME A SURE MENT.EX TRACT  ION 

ALPHA  :  UPDATE. STATE 

DATA  :  GHOST.IMAGE 

OATA  :  LOW. ELEVATION 

OATA  :  PAOAW.TYPE 

OATA  :  REDUNDANT. IMAGE 

OATA  :  RETURN. IMAGE.STATUS 

OATA  :  VAL  If)  .RETURN 

EVENT  J  ALLOCATE 

TNPUT.INTEHF ACE  :  RADAR. IN 

OUTPUT. INTERFACE  :  DATA.RECORD. 

AMBRFVIATED  BY! 

SYNONYM?  RESPRAD. 

ENABLED  RY: 

INPUT.INTERFACE:  RADAR. IN* 

TRACED  FROM? 

ORIGINATING.REQUIREMENT:  DPSPR_3_?J5.C.FUMCT!ONAL. 
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;  SKEDJ*.  . t ,  c no 

DESCRIPTION^  c0NSTRUCTS  THE  0R0EAE0  FILE  OF 

A  FRAME.". 


REFEBSAJ2i  .  INITIALISE  SKEOJ. 

ALPHA  t  PICK  ..CANO  I  OATES 
OAT  A  :  LAST.PULSE 
OAT A  :  MODE 
OATA  !  TEOF 

°FSnTLTT"«TRrHEFOE.IN.TR«K 

event  :  T_ 

FILE  :  CANDIDATE 
SUBNET  :  FORM_FRAME. 

en*blEeDvE9nYt!  schedule. 

TB*CESeCI SION s  RAOAR_SCHEOULER_PR I OR  IT  I Z  AT ION . 
STRUCC,TNSR0ER  OATA  .  HOOE 

0  ^»H‘ t” t7rEE  :-"-SE .IN-TRACK  SUCH  THAT 

(last„pulse^i.o/track.rate)<atcs  en0 

J  ««  saw  rwwu  M 

event  s 
terminate 

OTHERWISE 

TERMINATE 


R_NET  :  XMIT..R. 

DESCRIPTION! 

" X M I T _R  BUILDS  AND  FORWARDS  TO  THE  OUTPUT_INTERF ACt 
RAOAR_OUT  THE  COMMANDS  OF  THE  FRAME.''. 

REFERS  TO: 

ALPHA  :  FORM_Tl_T2 
ALPHA  :  FORM_T3 
ALPHA  :  PICK.COMMAND 
DATA  :  FOUND 
DATA  :  PADAR.TYPE 
EVENT  :  SCHEDULE 
EVENT  :  XRB 

OUTPUT.. INTERFACE  :  RADAR.OUT. 

ENABLED  BY: 

EVENT:  XRB. 

TRACED  FROM: 

DECISION:  RADAR_SCHEDULER_PRIORIT NATION. 

structure: 

ALPHA  :  PICK.COMMAND 
DO 

(FOUND) 

EVENT  :  XRB 

CONSIDER  DATA  :  RADAR_TYPE 
DO 

(T3) 

ALPHA  :  FORM.T3 
OTHERWISE 

ALPHA  :  FORMAT 1_ T2 

ENO 

OUTPUT  ..INTERFACE  :  RADAR_OUT 
OTHERWISE 

tvtNT  :  SCHtDULt 
TERMINATE 

END 
END  . 
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REFERENCE  :  CISS.TOP.BASELINE.CONSTRUCT, 

DESCRIPTION! 

" TRW  REPORT  NO.  22944.9771_RE.01t  VOLUME  It  REVISION  A 

REFERENCE  :  OPSPR.SPECIF ICAT ION. 

DESCRIPTION: 

"TRW  REPORT  NO.  27332.6921.015t  REVISION  It  CDRL  AOOEt 
SECTION  3.2”. 

REFERENCE  :  TLS_C2.DPS_INTERFACE.SPEC IFICATION. 

DESCRIPTION:  "TRW  REPORT  NO.  27332.6921.013. " • 

REFERENCE  :  TLS.ENVIRONMENT.AND.THREAT.MODEL* 

DESCRIPTION: 

"GRC  REPORT  NO.  DRC.72.25499  (SECRET) t  VERSION  I.". 

REFERENCE  .:  TLS.RADAR.DPS.INTERFACE.SPECIFICATION* 

DESCRIPTION:  "TRW  REPORT  NO.  27332.6921.012."* 

EXPLAINS: 

INPUT.INTERFACE:  RADAR.CLOCK.IN 

input.interface:  radar.in 

MESSAGE:  T1.T2.COMMAND 
MESSAGE:  T1.T2.RETURN 
MESSAGE:  T3.COMMAND 
MESSAGE:  T3.RETURN 
OUTPUT.INTERFACE:  RAOAR.OUT. 

REFERENCE  :  TLS_RADAR.PERFORMANCE.SPEC. 

DESCRIPTION:  "GRC  REPORT  NO.  CR.3.386  (SECRET) 

REFERENCE  :  TLS.SYSTEM.REO'JIREMENTS. 


"TRW  REPORT  NO.  27332.6921.015t  REVISION  It  CDRL  AOOE 
SECTION  1.1". 
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HESOLUTION.". 


SUBSYSTEM  :  SSC2. 

CONNECTEO  TO: 

IN°UT_lNTERFACE :  CC_iN 
OUTPUT_INTEPFACE:  CC_OUT. 

SUBSYSTEM  :  SSPEPMFL, 

CONNECTED  TO: 

OUTPUT.INTERFACE:  DATA.RF.CORD. 

SUBSYSTEM  :  SSRADAR. 

CONNECTED  TO: 

INPUT_INTERFACE:  RADAR_CLOCK_I N 
INPUT_INTERFACE:  RAOAR_lN 
OUTpUT _ I NT ERF  ACE  :  RADAROUT. 


SYNONYM  :  CKRADMES# 

EQUATES  TO: 

ALPHA :  ACCEPT.AND.CHECK.RADAR.RETURN.MESSAGE 

SYNONYM  t  CONTRESj 
ABBREVIATES: 

R.NET:  CONTROL. RESOURCES# 

SYNONYM  :  RAOIN. 

ABBREVIATES: 

INPUT.INTERFACE:  RADAR. IN# 

SYNONYM  :  RAOOUT. 

ABBREVIATES: 

OUTPUT.INTERFACE:  RADAR.OUT# 

SYNONYM  :  RESPRAO. 

ABBREVIATES: 

R.NET :  RESPONSE.TO.RADAR# 

SYNONYM  :  T1T2CMD. 

EQUATES  TOI 

MESSAGE:  T1.T2.COMMAND# 

SYNONYM  :  TIT2RTN# 

EQUATES  TO: 

MESSAGE:  T1.T2.RETURN# 

SYNONYM  :  T3CMD. 

EQUATES  TO: 

MESSAGE;  73.COMMAND# 

SYNONYM  :  T3RTN. 
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APPENDIX  F 

TLS  SOURCE  SPECIFICATIONS 
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I.  INTRODUCTION 


1.0  PURPOSE  AND  SCOPE 

This  report  presents  the  preliminary  Data  Processing  Subsystem  Per¬ 
formance  Requirements  (DPSPR)  for  the  Track  Loop  Experiment  (X-l).  The 
goals  for  this  experiment  are  presented  in  Section  2.0. 


The  primary  intent  of  this  document  is  to  provide  the  initiating 
input  to  the  Software  Requirements  Engineering  Methodology  which  will  sub¬ 
sequently  produce  a  Process  Performance  Requirements  (PPR)  specification 
for  the  Track  Loop  System  Data  Processing  Subsystem.  It  is  further  the 
intent  of  this  document  to  present  an  example  of  the  required  contents  and 
level  of  detail  of  a  DPSPR  discussed  in  Reference  1.  As  such,  this  example 
will  provide  a  more  concrete  basis  for  technical  exchange  between  the  Soft¬ 
ware  Requirements  Engineering,  DPSPR  and  VAV contractors.  Such  interchange  is 
considered  necessary  to  arrive  at  a  final  definition  of  the  required  form, 
contents  and  format  of  a  DPSPR.  Part  II  of  this  report  constitutes  the 
example  DPSPR. 


IP’ 
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1.1  The  Track  Loop  System 

The  Track  Loop  System  (TLS)  is  a  subset  of  a  Preliminary  Ballistic 
Missile  Defense  System  which  is  capable  of  nearly  autonomous  execution 
In  response  to  external  stimuli.  It  is  the  simplest  known  subsystem  with 
properties  of  interest  for  software  definition,  and  It  is  one  which  lias 
been  studied  extensively,  both  in  the  academic  literature  and  In  such 
practical  programs  as  Site  Defense.  Therefore,  It  has  been  selected  as 
the  testbed  for  supporting  experimentation  in  development  of  the  methodology 
for  software  requirements.  A  pictorial  representation  of  the  TLS  Is  provided 
In  Figure  F-l. 

1.1.1  Preliminary  Ballistic  Missile  Defense  System 

A  Preliminary  Ballistic  Missile  Defense  System  (PBMUS)  has  been 
postulated  as  an  environment  in  which  the  TLS  would  execute.  It  is  a 
generalized  representative  of  the  class  of  systems  currently  In  develop¬ 
ment,  and  Is  particularized  for  the  TLS  through  representative  but  non- 
real  specifications  where  required. 


RADAR  ORDERS 


RADAR  RETURNS 


Figure  F-l  Trick  Loop  Systwi 


The  top  level  flow  of  the  PBMDS  is  shown  in  the  functional  flow  block 
diagram,  Figure  F-2.  In  the  Conduct  Engagement  mode,  an  object  entering  the 
search  region  will  be  detected  and  designated,  tracked,  discriminated,  and 
engaged  (as  required)  in  defense  of  the  ground  facilities.  Those  functions 
are  implemented  through  the  Data  Processing  System  (DPS),  a  radar  or  other 
sensor,  and  a  means  of  neutralizing  hostile  objects.  For  the  purpose  of 
the  TLS,  only  the  radar  need  be  defined  in  detail;  other  system  elements 
are  identified  only  to  the  extent  that  they  impact  DPS  requirements. 

1.1.2  TLS  Requirements 

Functional  Requirements  on  the  TLS  would  normally  be  contained  in  a 
system  specification  (Level  1,  or  A  in  MIL  STD  490  terminology).  If  soft¬ 
ware  Is  developed  from  the  requirements  provided  in  Section  II  of  this 
report,  and  if  that  software  is  to  be  installed  and  exercised  in  the  field, 
then  such  a  systerp  specification  may  be  required.  In  the  interests  of 
both  economy  and  timeliness,  only  the  subsection  of  the  A  Specification 
required  for  the  DPSrR  is  provided  nere. 


1.1. 2.1  Initialization 

The  TLS  shall  accept  CZ  messages  for  initialization  with  the  following 
properties: 

a)  An  estimate  of  state  shall  be  generated  external  to  TLS  and  for¬ 
warded  to  TLS  over  the  communication  channel  to  initiate  tracking. 

b)  If  an  object  corresponds  to  that  estimate,  the  estimation  accuracy 
shall  be  such  that  the  expected  (1-sigma)  deviation  of  tne  object 
from  a  perfect  extrapolation  of  state  shall  be  In  accord  with 
Table  F.l. 

c)  Initialization  estimates  shall  be  provided  (handed  off)  at  a  rate  not 
exceeding  150  per  second  over  any  interval  greater  than  50  milli¬ 
seconds. 

d)  The  total  number  of  handoffs  shall  not  exceed  1500. 

e)  The  total  number  of  real  objects  shall  not  exceed  300. 

f)  A  handoff  may  be  an  estimate  on  a  real  object  or  an  estimate  relating 

to  a  state  at  which  no  object  is  located  (ghost).  Multiple  handoffs 
of  a  single  object  may  be  generated. 

g)  Each  handoff  shall  consist  of  a  unique  designator,  the  state  vector 
and  Its  covariance  matrix. 
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Table  F.2  Table  F.l 

Handover  Errors 

In  Radar 

Face  Coordinates 

COORDINATE 

MINIMUM 

MAXIMUM 

mjs 

R 

3 

5 

M 

U 

0.4 

0.6 

mslne 

V 

0.03 

0.05 

msine 

• 

R 

40 

55 

m/sec 

• 

U 

2 

4 

mslne/sec 

• 

V 

2 

4 

mslne/ sec 

l  NOTES: 

1.  All  data  l-o 

2.  Handover  altitude  L  65  K  meters 


i 
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1.1. 2. 2  Terminatior 


a)  Redundant  images  of  objects  shall  be  dropped  from  track  in  order  to 
conserve  radar  resources.  The  probability  of  dropping  track  on  a 
non-redundant  image  shall  be  considered  in  determining  leakage. 

b)  Ghosts  shall  be  dropped  from  track  in  order  to  conserve  radar 
resources.  The  probability  that  a  non-redundant  image  is  dropped 
as  a  ghost  shall  be  considered  in  determining  leakage. 

c)  For  flight  safety,  no  track  pulse  shall  be  commanded  with  true  elevation 
angle  less  than  3°. 

d)  Track  shall  be  dropped  in  response  to  an  external  command  repre¬ 
senting  handoff  to  another  defense  facility  or  successful  intercept. 

No  track  pulse  shall  be  transmitted  to  a  designated  image  more  than 
100  milliseconds  after  such  a  command  appears  at  the  TLS  port,  with 
probability  .3. 

1.1. 2. 3  Tracking 


a)  The  TLS  shall  generate  state  estimates  sufficient  to  support  discrimi 
nation  through  beta  estimation  accuracy  in  accordance  with  Figure  F-3 
and  impact  point  prediction  in  accordance  with  Figure  F-4. 

Beta  is  required  in  the  system  for  a  variety  of  purposes  at  different 
stages  in  the  engagement  of  an  object.  Early  in  track,  it  is  used 
for  junk  rejection ;  at  an  intermediate  state,  it  forms  a  key 
element  of  discrimination  in  elimination  of  decoys  and  assessment 
of  the  danger  imposed  by  an  RV ;  shortly  thereafter,  it  is  essential 
to  intercept  planning  in  estimating  the  intercept  point.  The  needs 
overlap  in  practice,  so  that  a  corrnon  ordinate  for  the  plot  of 
accuracy  requirements  is  needed.  But  each  of  the  aspects  of  use  of 
beta  dictates  a  different  ordinate  at  the  system  level.  The  ordinate 
selected  in  Figure  F-3  is  time  in  track ,  a  parameter  known  to  be 
useful  to  the  Software  Requirements  Engineer,  and  as  useful  for 
the  systems-level  definition  as  any  of  the  other  choices. 

Similarly,  impact  point  prediction  is  used  initially  to  reject  cross 
traffic,  then  to  assess  the  threat  posed  by  an  RV;  in  some  schema, 
it  also  assists  discrimination.  The  first  might  be  expressed  by  the 
system  engineer  in  terms  of  accuracy  against  track  energy;  the 
second  in  terms  of  time  to  commit  contour  (which  is  in  tiam  a 
function  of  RV  type,  intercept  capabilities,  and  other  parameters) . 
Again,  time  in  track  was  chosen  as  a  convenient  ordinate  for  the 
error  requirements  in  Figure  F-4. 

b)  The  TLS  shall  generate  state  estimates  sufficient  to  support  object 
Intercept  in  accordance  with  Figure  (TBD). 

c)  Leakage  Is  here  defined  to  be  the  probability  that  all  images  of 
a  real  object  entered  at  an  altitude  not  less  than  150K  feet  are 
dropped  from  track  for  any  reason  other  than  the  minimum-elevation 
constraints  or  external  command  defined  in  1.1. 2. 2.  Leakage  in 
TLS  shall  not  exceed  .03. 
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1.1. 2. 4  Resource  Control 


a)  The  TIS  shall  commit  to  tracking  functions  not  more  than  1000  radar 
pulses  per  second,  using  not  more  than  25  kilowatts  ERP. 

b)  The  TLS  shall  commit  to  tracking  functions  not  more  than  2500  joules 
per  object.” 


1.1. 2. 5  Data  Recordinc 


The  TLS  shall  provide  records  for  post  test  analysis  of  the  following 
data: 


a)  Time  of  handoff  and  designator  and  estimate  received. 

b)  Time  of  termination  of  track  on  each  designation  with  reason 
for  termination. 


c)  At  intervals  not  greater  than  100  milliseconds,  the  estimate  of 
state  for  each  designation  received  and  not  yet  terminated. 

That  estimate  shall  consist  of  the  following  data:  position, 
velocity,  a  beta  estimation  parameter  and  estimates  of  the 
uncertainty  of  each. 

d)  At  intervals  not  greater  than  300  milliseconds,  the  usage  of 
radar  resources.  That  measure  shall  include:  radar  energy  profile 
and  DPS  estimates  of  expected  and  maximum  energy  commanded. 
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2.0  SREP  OBJECTIVES  FOR  X-l 


a)  Demonstrate  the  scope,  contents  and  level  of  detail  of  the  DPSPR, 
described  in  Reference  1,  and  transmit  the  results  to  the  DPSPR 
contractors  for  their  evaluation. 

b)  Demonstrate  the  scope,  contents,  format,  and  level  of  detail  of 
PPR  Volume  I  specified  in  Reference  2.  The  PPR  will  be  written 
In  preliminary  RSL  (see  Reference  4).  In  particular: 

1)  Evaluate  the  format  of  the  PPR  described  In  Reference  2  for 
completeness  and  adequacy. 

2)  Evaluate  the  adequacy  of  the  preliminary  RSL  definition  for 
stating  requirements. 

3)  Provide  the  PPK  for  evaluation;  In  particular,  the  form  and 
content  of  the  performance  requirements. 

4)  Evaluate  the  extent  of  the  traceability  of  the  PPR  to  the 
DPSPR. 

c)  Evaluate  the  steps  of  SREM  (see  Reference  3)  from  the  DPSPR  to  a 
PPR;  In  particular,  the  procedural  steps,  form,  and  content  of  the 
performance  allocation  activities. 

d)  Exercise  the  available  experimental  software  to  generate  portions 
of  the  PPR  (e.g.,  the  structure  segment  of  RSL). 
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3.0  LIMITATIONS 


I 

i 


Two  primary  forces  limit  the  application  of  the  DPSPR  of  Section  II. 
The  first  is  the  result  of  excising  the  track  loop  from  the  total  PBMOS. 
Although  the  loop  is  nearly  self-contained,  it  has  extensive  interfaces 
both  in  terms  of  requirements  and  in  the  sense  of  implementation  with  other 
software  functions.  Consequently,  requirements  are  imposed  on  TLS  which 
originate  or  terminate  within  the  DPS  in  ways  and  to  an  extent  not  believed 
appropriate  for  a  true,  functional  system. 

The  second  major  area  of  limitation  arises  from  the  novelty  of  the 
approach.  While  the  methodology  employed  is  believed  valid,  it  has  not 
yet  been  tried.  (In  fact,  this  experiment  is  its  trial.)  Consequently, 
it  is  likely  that  this  initial  DPSPR  wiil  be  found  to  be  incomplete  in  some 
materials  needed  for  the  PPR  and  for  software  development.  Every  effort  has 
been  made  to  anticipate  such  failings,  but  we  anticipate  methodologic  bugs 
in  the  same  way  we  would  expect  to  find  bugs  in  a  new  compiler  or  uthsr 
major  software  development. 

3.1  System  Objectives 

Isolation  of  TLS  from  PBMDS  was  artificial,  and  the  objectives  of 
Section  1,1  are  correspondingly  less  than  real.  The  selection  of  those 
objectives  was  based  on  simplicity  of  Implementation,  expected  usefulness 
•  of  the  TLS  as  a  testbed,  and  availability  of  comparison  criteria.  Since 
no  DPSPR  had  ever  been  prepared  before,  it  was  not  possible  to  select 
criteria  to  optimize  its  quality.  The  objectives  provided  are  believed 
to  be  good  for  generation  of  the  DPSPR,  but  cannot  be  shown  to  be  optimal. 

.  3.2  Allocation  to  DP 

Again,  the  absence  of  precedent  and  the  artificiality  of  the  TLS  make 
an  "optimum"  allocation  of  functions  unreasonable.  A  complete  allocation 
Is  provided,  which  Is  believed  to  be  sufficient  for  the  experiment. 

3.3  Level  of  Detail 

The  objective  of  the  DPSPR  of  Part  II  is  to  provide  the  complete 
specification  required  for  the  PPR  Feasibility  Demonstration.  It  Is  likely 
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that-  some  of  the  material  will  prove  to  be  unnecessary.  It  Is  certain  th 
not  .11  data  presently  missing  will  be  required  before  Initiating  work  on 
volume  I  of  the  PHI.  Therefore,  revisions  are  planned  both  to  complete 
specification  of  the  requires  and  to  delete  data  found  to  be  non-essential. 

3.4  FnrmnlEtion  DP  Requirements, 

The  X-1  DPSPR  defines  some  data  In  a  form  and  to  a  depth  we  feel  to 
undesirable.  In  particular,  efforts  are  now  under  way  to  express  requ  re¬ 
lent  on  Redundant  Track  Elimination  In  terns  of  total  radar  energy  per 
:  ect  Converting  both  redundant  tracking  and  other  explicit  requirements 
to  a  derivable  fom  will  te  an  objective  for  revisions  of  the  PPSPR. 

3.5  Corollary  Documents 

The  DPSPR  is  one  document  In  a  family  required  to  develop  the  Process 
Performance  Requirements  (PPR).  For  the  TLS.  the  other  documents  are: 

§  TLS  System  Requirements 

•  TLS  Radar/DPS  Interface  Specification 

•  TLS  C^/DPS  Interface  Specification 

t  ,„_TLS  Radar  Performance  Specification  ^ 

•  TLS  Environment  and  Threat  Model  Definition. 

The  system  requirements  are  sketched  In  Section  1.1  above.  The  starred  (*)  docu- 
rnents  In  this  family  are  not  yet  prepared. 

For  the  purposes  of  development  of  the  PPR.  the  absence  of  the  docu- 
Ts  Sieved  to  be  less  than  critical.  For  th,  X-1  effort,  the  contents 
of  th.  missing  specifications  are  subsets  of  th,  corresponding  Terminal 
Defense  Program '(TDP)  documents.  Therefore,  the  required  Infomatlon  for 
the  PPR  Is  available  from  TOP  documentation.  However,  a  property  of 
methodology  ls  lts  recognition  that  not  all  specifications  ultlm.t.lyjqu.rad 
to  support  software  design  will  be  available  early  In  ‘»>.t  design  effort. 

To  the  extent  that  the  TLS  documentation  corresponding  to  Initiation  o 
PPR  is  required,  th,  TDP  docents  a.,  excessive.  Thus,  there  Is  an  effort 
red  as  a  part  of  the  ongoing  work  to  edit  th.  TDP  material  to  the 

specific,  appropriate  contents  for  th,  stag,  of  development  * 

r,  DPSPR.  That  work  is  under  way  on  th,  Radar/DPS  Interface  specification, 
ind  will  soon  be  undertaken  on  th.  other  elements  of  the  DPSPR  package. 
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II.  DATA  PROCESSING  SUBSYSTEM 
PERFORMANCE  REQUIREMENTS  -  TRACK  LOOP  SYSTEM 


1.0  SCOPE 

This  specification  establishes  the  functional,  performance,  design 
and  test  requirements  for  the  Track  Loop  System  (TLS)  to  the  extent 
necessary  to  develop  the  Process  Performance  Requirements  (PPR)  for  the 
Data  Processing  Subsystem  (DPS)  portion  of  the  system.  The  TLS  is  a  test 
configuration  of  an  integral  element  of  a  Preliminary  Ballistic  Missile 
Defense  System  (PBMDS). 

The  primary  objective  of  this  specification  is  to  constrain  the  DPS 
so  that  it  fulfills  the  intended  obligations  to  the  functions  and  perfor¬ 
mance  of  the  overall  TLS  of  which  it  is  a  part.  To  accomplish  this,  this 
specification 

•  Identifies  the  TLS  mission  and  performance  goals. 

•  identifies  the  various  subsystems,  their  functional  capa¬ 
bilities,  and  the  interfaces  between  the  Data  Processing 
Subsystem  and  each  of  the  others. 

•  allocates  a  portion  of  the  system  performance  to  the 
Data  Processing  Subsystem. 

•  describes  the  system  operational  design,  i.e.,  how  the 
subsystems  are  to  be  used  in  order  to  achieve  the  system 
performance  goals  by  utilization  of  the  subsystem  capa¬ 
bilities. 

This  specification  provides  the  technical  basis  for  the  development  of  the 
DPS,  but  is  not  a  TLS  system  specification. 
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2.0  APPLICABLE  DOCUMENTS 

2.1  TRW  Report  27332-692,-003,  (CORL  A004), 

Revision  1,  December  12,  1975, 

2-2  M-System  Requirements,  (Part  I.  Section  1.1  of  this  report). 

2-3  ly-WPiRjterfa^  TRW  ^ 

Its  C  /OPS  Interface  Specification  TRW  Report  Wo.  27332-6921-013 

2.5  Iks .Radar  Performance  Specification 

2.6  Iklinvim^  Model  Definition 
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3.0  DATA  PROCESSING  SUBSYSTEM 


The  TLS  Is  defined  in  [2.2]  (Part  I,  Section  1.1  of  this  report). 

Section  1.1.2  provides  the  system  requirements,  while  Figure  F-l  represents 

the  operation  of  the  system.  TLS  consists  of  a  radar  and  a  data  processor, 

2 

and  receives  input  data  from  radar  echoes  and  from  interface  with  the  C 
system.  A  model  of  the  system  environment  is  to  be  provided  as  [2.6]. 

Within  the  TLS,  the  radar-data  processor  interface  specification  is  to  be 
[2.4],  while  the  C2/DPS  interface  will  be  defined  in  [2.3].  The  radar  models 
will  be  in  [2.5], 

The  TLS  DPS  has  been  allocated  requirements  from  those  establisned  on 
the  TLS  as  a  whole.  The  resulting  requirements  on  the  DPS  are  defined  in 
Section  3.2  of  this  DPSPR.  Traceability  of  the  DPSPR  requirements  to  the 
TLS  requirements  is  shown  in  Figure  F-6.  All  TLS  requirements  not  allocated 
to  the  DPS  are  satisfied  by  the  radar.  Quantitative  verification  of  the 
sufficiency  of  the  allocation  will  be  undertaken  in  the  preparation  of  the 
PPR. 

3.1  Traceability 

Figure  F-6  is  the  traceability  matrix  for  this  DPSPR,  and  illustrates 
the  relationship  between  the  TLS  requirements  [2.2],  and  the  DPS  requirements 
of  Section  3.2.  It  also  depicts  the  allocation  of  portions  of  system  require- 
,  ments  to  the  radar;  not  all  of  that  allocation  is  clearly  visible  in  the 
interface  specification,  some  of  it  being  located  in  [2.5]. 

The  function  of  the  traceability  matrix  ie  twofold:  to  locate  the  sub¬ 
system  requirements  derived  from  each  system  requirement ,  and  to  facilitate 
.  recognition  that  each  DPS  requirement  originates  from  an  appropriate  source. 

The  first  function  is  insurance  that  the  DPSPP  (and  its  counterparts  for  other 
subsystems)  are  sufficient  tc  embody  the  system  requirements,  while  the  second 
verifies  that  no  gratuitous  requirements  nave  been  introduced. 

To  determine  the  source (s)  of  a  DPS  requirement ,  the  appropriate  row  is 
looated  in  the  left-hand  column.  Reading  across  the  row,  an  entry  of  "C" 
indicates  that  virtually  complete  satisfaction  of  the  system  requirement  for 
that  column  is  provided.  A  :'P"  indicates  that  a  portion  of  the  system  require¬ 
ment  is  there  satisfied.  Scanning  the  entire  chart ,  one  finds  t)iat  the  DPS 
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requirement  to  satisfy  the  interface  specification  is  not  traceable  to  the 
system  requirements ;  however ,  it  is  clearly  required ,  and  is  clearly  in¬ 
appropriate  for  the  system  specification. 


Determining  the  impact  of  a  system  requirement  on  the  subsystems  is 
constructive  both  in  confirming  that  every  requirement  is  covered  and  in 
tracking  the  consequences  of  a  change  to  the  system  specification.  Reading 
a  column  will  show  the  partial  (P)  or  complete  (C)  satisfaction  of  a  system 
requirement  in  the  corresponding  DPSPR  section.  In  the  present  case ,  each 
system  requirement  has  some  DPS  impact;  that  might  not  be  true  in  general. 

For  example,  if  a  hard  stop  on  elevation  angle  were  implemented  in  the  radar, 
then  the  third  requirement  voider  3.2.2  would  be  deleted ,  and  the  implementa¬ 
tion  of  the  third  requirement  of  (Part  1}  1.1. 2. 2  would  be  virtually  completely 
contained  in  the  radar  subsystem. 

3.2  Data  Processing  Subsystem  Requirements 

Many  of  the  following  specific  requirements  are  stated  In  terms  of  a 
value  and  a  probability  of  its  satisfaction.  In  each  such  case,  the  inter¬ 
pretation  shall  be  that  at  every  point  in  the  engagement,  the  probability  of 
satisfying  the  inequality  shall  be  at  least  the  stated  value.  The  required 
confidence  in  that  assertion  is  established  in  test  planning. 

3.2.1  Initialization 

a)  The  DPS  shall  accept  commands  from  the  C2  to  initiate  track  on  a 
designated  object.  A  radar  order  in  response  to  such  a  command 
shall  be  provided  at  the  radar  interface  for  transmission  within 

55  milliseconds  of  the  command  with  probability  .9.  These  commands 
are  defined  in  Reference  2-4  [TLS  CvDPS  Interface  Specification]. 

b)  Capacities.  The  UPS  shall  be  able  to  accept  handoffs  at  a  rate 
of  150  per  second  over  any  interval  greater  than  DO  milliseconds, 
and  a  total  of  1500  handoffs  per  engagement,  of  which  up  to  300 
will  be  real  images. 

3.2.2  Termination 

a)  The  DPS  shall  command  not  more  than  15  pulses  to  a  redundant  image 
with  probability  .7,  nor  more  than  50  with  probability  .99. 
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b)  The  OPS  shall  command  not  more  than  seven  pulses  to  a  ghost  with 
probability  .7. 

c)  The  DPS  shall  command  no  track  pulse  with  elevation  angle  less  than 
3°. 

d)  The  DPS  shall  command  no  track  pulse  to  an  image  of  an  object  which 
has  achieved  an  elevation  of  less  than  5°,  or  which  will  attain 
such  an  elevation  by  the  time  of  transmission,  with  probability  .9. 

e)  For  an  image  on  which  a  drop-track  command  is  received,  the  DPS 
shall  command.no  transmission  with  execution  time  more  than  100 
milliseconds  after  appearance  of  the  ord^r  at  the  interface 

with  probability  .7,  nor  more  than  300  milliseconds  with  probability 
.99. 

3.7.3  Tracking 

a)  The  DPS  shall  maintain  an  estimate  of  state  for  each  image  in  track. 
Defining  the  true  state  of  an  Image  by  Attachment  A,  estimated 
state  shall  deviate  from  true  state  by  not  more  than  the  tolerance 
of  Figure  F-7  (TBr<)  with  the  probabilities  of  that  Figure,  where 
the  assessment  is  relative  to  the  time  of  the  last  processed  return. 

b)  The  probability  that  all  images  of  an  object  shall  be  dropped  as 
redundant  shall  not  exceed  .01. 

c)  The  probability  that  any  Image  of  an  object  shall  be  dropped  as 
a  ghost  shall  not  exceed  .2. 

d)  The  DPS  shall  command  track  pulses  at  a  rate  sufficient  to  keep  the 
propagated  error  defined  by  Attachment  B  less  than  the  tolerances 
of  Figure  F-8  (TBD)  with  probabilities  defined  in  that  Figure. 

e)  The  DPS  shall  provide  orders  to  the  radar  in  accordance  with  the 
Interface  specification.  The  relevant  fields,  timing,  etc.,  are 
defined  in  [2.3].  In  particular,  the  DPS  shall  select  waveforms, 
frequencies,  beamwidths  and  related  parameters  in  accordance  with 
radar  constraints  in  order  to  satisfy  TLS  performance  requirements. 

f)  The  DPS  shall  accept  radar  returns  in  accordance  with  the  Interface 
Specification  [2.3]. 

g)  The  DPS  shall  maintain  track  on  each  Image  until  one  of  the  following 
conditions  is  satisfied: 

1)  Drop  Track  command  received, 

2)  Image  determined  to  be  redundant, 

3)  Image  determined  to  be  a  ghost,  or 

4)  Estimated  elevation  of  object  or  of  image  expected  to  violate 
elevation-angle  constraint  before  next  assessment. 
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3.2.4  Resource  Control 


a)  The  OPS  shall  maintain  an  estimate  of  radar  energy  scheduled  by 
track  functions  which  shall  be  within  three  percent  of  the  energy 
nominally  expended,  and  an  upper-bound  estimate  such  that  the 
actual  ERP  and  total  radiated  energy  do  not  exceed  the  bound  with 
probability  (T8D). 

b)  The  DPS  shall  allocate  radar  commands  so  that  not  more  than  (TBD) 

joules  are  commanded  per  image  nor  more  than  (TBD)  kilowatts  or  (TBD) 
pulses/second  for  all  images  in  track. 


3.2.5  Data  Recording 

The  DPS  shall  output  to  permanent  file  the  following  data: 

a)  Time  of  handoff  and  designation  and  estimate  provided, 

b)  Time  of  termination  of  track  on  etch  designation  with  reason 
for  termination.  The  reason  shall  be  one  of  the  following. 

1)  Drop  Track  Command 

2)  Minimum  Elevation 

3)  Image  Declared  Redundant 

4)  Image  Declared  Ghost. 

c)  Subsequent  to  each  state  update,  the  resulting  estimate  af 
state  on  that  Image.  Contents  of  that  estimate  are  TBD. 

d)  At  Intervals  not  greater  than  300  milliseconds  the  usage  of 
radar  resources.  That  estimate  shall  include  the  nominal 
and  upper  bounds  defined  in  3.2.4,  and  TBD  additional  data. 
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4.0  GLOSSARY 


State  Vector:  A  set  of  data  pertaining  to  a  specified  image  defining  Its 
location  in  space  and  permitting  extrapolation  of  its  location  to 
other  times.  The  contents  of  the  state  vector  may  vary  with  different 
applications;  1r  particular,  the  coordinate  system  employed  is  dependent 
on  the  use  to  which  it  will  be  put.  A  conventional  state  vector  in 
RFCC  is:  R,  U,  V,  R,  U,  V,  and  the  time  to  which  all  are 
referenced. 

Object;  A  physical  entity  external  to  the  DPS  with  radar  reflection  properties 
corresponding  to  a  reentry  vehicle  of  the  defined  threat. 

Image;  A  target  defined  to  the  TLS  DPS  for  tracking  and  categorization  as  the 
image  to  be  tracked,  a  redundant  image,  or  a  ghost. 


Ghost;  An  image  with  which  no  object  is  correlated. 

Redundant  Image;  An  image  which  correlates  with  both  an  object  and  another 
Image.  Of  the  set  of  redundant  Images  of  an  object,  one  Is  Intended  to 
be  retained  in  track  while  the  others  are  categorized  as  redundant 
and  dropped. 

Handoff;  The  receipt  by  the  TLS  OPS  of  a  valid  order  to  initiate  track  on 
an  Image, 

Track  Termination;  The  receipt  by  the  TLS  DPS  of  a  valid  order  to  Drop 

Track,  or  the  determination  by  the  DPS  that  tracking  should  be  terminated. 
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ATTACHMENT  A 


» 


STATE  VECTOR  PREDICTION 


The  filter  maintains  the  state  vector  in  the  RFCC  system  at  all  times. 
Specific  details  of  the  equations  of  motion  and  the  method  of  trajectory 
Integration  employed  for  state  vector  prediction  in  the  RFCC  system  are 
presented  in  this  section.  Figure  A-l  defines  the  RFCC  system. 


1.1  Equations  of  Motion 


In  the  general  formulation  of  the  equations  of  motion,  it  is  assumed 
that  all  vector  variables  appearing  in  the  differential  equations  are 
appropriately  referenced  to  the  RFCC  system  associated  with  the  face  of  a 
given  radar  under  consideration.  Explicit  expressions  for  the  transformed 
variables  are  given  whenever  they  first  appear. 


Let  the  RFCC  position  vector  to  a  target,  denoted  r^,  have  Cartesian 
components  Xf,  Y*  and  Zf.  The  differential  equations  describing  the 
motion  of  a  target  In  the  rotating  RFCC  system  may,  in  general,  ,r1tten 
as 


-  2  Uj  x 


(uf  x  Rf) 


(A.l) 


and  assuming  constant  x  model 

X  *  0 

where 

u  »  GM 

G  ■  universal  gravitational  constant 
M  ■  mass  of  the  earth 

ftf  is  the  vector  from  the  geocenter  to  the  target 

p  Is  the  atmospheric  density  which  is  a  function 

of  the  altitude  h 

g  ■  earth's  sea  level  gravity 

X  is  the  Inverse  of  the  ballistic  coefficient 
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k  ■ 


* 


ry  is  the  velocity  vector  of  the  target 

x  is  the  vector  cross-product 

u>r  earth's  angular  rotation  rate,  a  vector 
quantity  resolved  along  an  eartn-centered 
Cartesian  coordinate  system  aligned  with  the 
RFCC  system. 


Define  as  the  vector  from  the  geocenter  to  the  radar  site  expressed 
in  the  RFCC  system.  Then 

5f  *  +  7f  (A. 2) 


where  the  vector  Rsf.  is  given  by 


0 


R  Cos  E 
e 

II  S  in  E 


(A.3) 


and  E  is  the  elevation  angle  of  the  radar  boresight  with  respect  to  the 
local  horizon  plane. 

The  earth  rotates  about  the  polar  axis  with  a  constant  angular 
velocity  oje.  The  components  of  the  earth's  angular  velocity  vector  in  the 
RFCC  system  is  given  by 


V 

<a>  Sin  A  Cos 
c 

CJ  ■ 

f 

\ 

X, 

»  (Cbs  E  Sin  -  Sin  E  Cos  A  Cos  <J) 

w  (Cos  A  Cos  E  Cos  <>  +  Sin  E  Sin  <t) 
e  T  * 

where  A  Is  the  azimuth  of  the  radar  boresight  with  respect  to  the  radar 
centered  horizon  coordinate  system  and  $  is  the  geocentric  latitude  of  the 
radar  site. 

1.2  Trajectory  Integration 

The  trajectory  Integration  involved  in  the  prediction  of  the  state 
vector  will  be  performed  by  a  second-order  Taylors  series  expansion  In 
atn  *  tn+j  -  t  for  the  position  vector  r^  which  gives 

) 

I 
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fflW  ■  '{<*„>  +  ;f<«n>Atn  +  1/2  'f(tn)4tn 


(A.5) 


and  consequently,  the  velocity  vector  is  given  by 


VW  ’  V'n1  + 


(A. 6) 


and 


*<t 


(A.?) 


where  rf(tn)  is  readily  evaluated  from  Eq.  (1.1)  by  using  the  current 

estimate  of  the  state  vector  at  t. 
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ATTACHMENT  B 


PROPAGATION  OF  ERRORS 

Ignoring  the  process  noise,  the  propagation  of  the  state  error  covariance 
matrix  from  cycle  to  cycle  is  computed  by 

%  P(n+l/n)  »  *(nfl,n)  P(n)  i-T(n+l,n)  (B.l) 

in  which  #(n+l,n)  Is  the  state  transition  matrix  expressed  in  terms  of  the 
appropriate  filter  coordinate  system  (RVCC). 

The  derivation  of  the  4>  matrix  starts  with  the  first  order  Taylor's 
expansion  of  a  set  of  nonlinear  differential  equations  describing  the  target 
motion  about  some  nominal  solution  of  the  state.  For  this  specific  develop¬ 
ment,  the  target  motion  Eq.  (A.l)  is  approximated  by 


1  .  -  9JSJ  If  I  x 
rf  2  '  rf  t 


(B.2) 


that  is,  all  other  accelerating  forces  except  that  due  to  the  atmospheric 
drag  are  ignored. 

The  decoupled  in-plane  and  out-of-plane  transition  matrices  and 
*n  in  the  RVCC  system  are  given  by 


♦  (n+l,n) 
P 


-DZ.A 
1  n 

-DZ.An 

c 


♦  (n+l,n)  - 
n  0  1 


1  A 


(B.3) 


(B.4) 


1.0  SCOPE 


This  specification  defines  the  physical  and  functional  interface  between 
the  Radar  and  the  Data  Processing  Subsystem  (DPS)  of  the  Track  Loop  System  (TLS). 
The  TLS  itself  Is  a  testbed  derived  from  a  Preliminary  Ballistic  Missile  Defense 
System  (PBMDS),  which  is  in  turn  a  representative  but  unreal  environment  for 
these  studies.  TLS  Is  Intended  to  have  development  and  test  capability, 
although  realization  of  that  capacity  in  actual  testing  is  not  no;.'  contemplated. 

This  specification  corresponds  to  one  which  would  be  available  prior 
to  preparation  of  a  PPR.  To  that  end,  its  contents  have  been  extracted  from 
TDP  documentation.  Reference  is  made  to  that  material  as  the  source  from 
which  data  here  labelled  and  "TBDn  will  be  derived.  In  this  publication 

nTBS"  is  used  to  identify  material  expected  to  be  required  during  early  stages 
of  PPR  preparation ,  while  "TBD"  denotes  material  which  may  be  supplied  later  in 
the  specification  process.  Material  presented  in  italics,  such  as  this 
paragraph ,  is  illustrative  or  informative  in  nature,  and  would  not  normally 
appear. in  such  a  specification. 

Some  of  the  paragraphs  in  this  Interface  Specification  place  constraints 
or  requirements  on  the  DPS ;  these  have  been  identified  by  a  *  in  front  of  that 
paragraph. 


{ 
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2.0  APPLICABLE  DOCUMENTS 


2.1  TLS  SYSTEM  REQUIREMENTS  27332-6921-011,  PART  I,  SECTION  1.1 

2.2  TLS  DATA  PROCESSING  SUBSYSTEM  PERFORMANCE  REQUIREMENTS  (DPSPR)  27332- 
6921-011,  PART  II 

2.3  TLS  RADAR  PERFORMANCE  SPECIFICATION 

2.4  TLS  ENVIRONMENT  AND  THREAT  MODEL  DEFINITION 


3.0  INTERFACE  REQUIREMENTS 


3.1  PHYSICAL  INTERFACE 

TBD 

The  physical  interface  is  highly  dependent  on  hardware  selection  for 
bath  the  DPS  and  the  Radar ;  in  general ,  it  will  be  irrelevant  to  the  speci¬ 
fication  process  through  the  Preliminary  Design  Review.-  Some  portions  of 
the  physical  interface  may  be  specified  during  PPR,  notably  those  relating 
to  timing  of  signals  and  clock  protocol. 

3.2  FUNCTIONAL  INTERFACE 

The  functional  Interface  between  the  DP  and  the  Radar  shall  consist  of: 
§  Commands  Issued  by  the  UP  to  the  Radar 

•  Returns  Issued  by  the  Radar  to  the  DP 

•  Engagement  Clock  Issued  by  the  Radar  to  the  DP 

3.2.1  Radar  Command  Generation 

.a.  The  Radar  will  execute  only  the  commands  issued  by  the  UP. 

*  b.  Each  command  shall  contain  transmit,  receive  and  synchronization 
data  as  described  herein. 

c.  The  radar  shall  transmit  one  pulse  for  each  command  which  satisfies 
the  radar  and  Interface  constraints.  Within  PBMDS,  but  external  to  TLSt 
there  are  exceptions  for  pulse  pairs  and  for  verify  pulses. 

*  d.  The  DPS  shall  command  a  single  receive  window  for  each  pulse. 

Within  each  receive  window,  the  DPS  shall  conmand  at  least  one  receive  gate. 

3.2.2  Command  Ordering 

a.  Radar  shall  execute  commands  in  the  order  received. 


*  b.  The  DPS  shall  provide  End  of  Transmission  at  least  1  mse-  before 
the  scheduled  execution  time  of  the  first  command  In  the  message. 

3.2.3  Command  Unpacking  and  Decoding 

*  The  DPS  shall  Issue  commands  In  accordance  with  the  format  of  TBD. 
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3.2.4  Timing  Control 

'  a.  The  commanded  times  for  Radar  actions  or  for  returns  shall  be  In 
absolute  time  measured  from  a  clock  with  nominal  1.68  second  rollover.  The 
least  significant  time  bit  shall  be  6.25  nsec. 

b.  Radar  shall  determine  all  intermediate  times  needed  to  comply  with 
command  data  for  transmission  and  reception. 

r  c.  The  DPS  shall  not  command  receive  windows  which  overlap.  The 
receive  window  duration  in  each  case  shall  be  at  least  the  uncompressed  pulse 
length  plus  the  desired  range  coverage. 

d.  The  DPS  shall  not  command  conflicting  transmissions.  Consecutive 
commands  shall  be  separated  in  execution  time  by  at  least  the  uncompressed 
pulse  length  of  the  earlier  plus  TBS. 

3.2.5  Command  Contents 

a.  The  DPS  shall  provide  a  waveform  Identifier  corresponding  to  one  of 
the  waveforms  of  Table  F.2  (TBD)  in  each  command. 

b.  The  DPS  shall  provide  in  each  command  both  transmit  and  receive  codes 
corresponding  to  direction  cosine  phase  tapers. 

*  r..  The  DPS  shall  provide  a  receiver  gain  setting  in  each  receive  window, 
d.  The  DPS  shall  provide  a  signal  processing  mode  code  In  each  receive 

gate. 

s  e.  The  DPS  snail  provide  a  fixed  signal  acceptance  threshold  and  threshold 
type  selection  for  each  receive  gate. 

f.  The  DPS  shall  provide  the  range  gate  mark  generation  technique  for 
each  receive  gate. 

*  g.  The  DPS  shall  provide  the  transmit  power  level  for  each  command. 

3*2.6  Return  Contents 

a.  Radar  shall  return  Identifier  data  provided  In  the  command. 

b.  Radar  shall  return  actual  range  mark  times  and  the  signal  amplitude 
at  each  range  mark. 

c.  Radar  shall  return  video  signal  amplitudes  at  conmanded  points. 

■  » 

Amplitude  shall  be  corrected  by  the  Radar  for  stored  Instrumental  errors. 
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d.  For  appropriate  commanded  signal-processing  modes  and  waveforms, 
the  Radar  shall  return  direction  cosines  of  the  echo.  Directional  data  shall 
be  corrected  by  the  Radar  for  stored  instrumental  errors. 

e.  For  appropriate  commands,  the  Radar  shall  return  TBS  wake  array  data. 

f.  Radar  shall  return  noise  level  relevant  to  each  amplitude  in  a  return. 

3.2.7  Error  Handling 

a.  Radar  shall  return  an  error  message  for  each  discernible  command  not 
Implemented.  That  message  shall  include  a  code  corresponding  to  the  reason 
for  the  failure  of  transmission.  Among  the  reasons  may  be  preemption,  receive 
or  transmit  window  overlap,  insufficient  time  for  transmission,  and  faulty 
command  (internal  inconsistency). 

*  b.  The  DPS  shall  initiate  a  record  on  permanent  file  of  each  error  return. 

►  c.  The  DPS  shall  determine  whether  the  fault  is  persistent  or  unique; 

If  persistent,  whether  it  is  safety-related.  (Definitions  TBS).  A  persistent, 
safety-related  fault  shall  cause  test  termination  to  he  commanded  by  the  DPS 
within  TBS  milliseconds;  in  particular,  no  command  shall  be  issued  for  trans¬ 
mission  by  the  Radar  more  than  TBD  milliseconds  after  a  persistent,  safety- 
related  fault  is  detectable  from  returns. 

3.2.8  Mode  Change 

*  The  DPS  shall  control  all  Radar  mode  changes  through  Issuance  of 
appropriate  commands.  The  changes  shall  include  startup  and  shutdown.  Time¬ 
line  constraints  on  mode  changes  and  on  preparation  time  for  transmission  are  TBS. 

3.2.9  Timing 

a.  Radar  shall  provide  a  master  timing  reference  to  DPS  via  TBS  Interface. 

b.  The  clock  shall  provide  2B  bits  of  data  with  a  least  significant  bit 
of  6.25  nsec. 

c.  The  resetting  of  the  clock  shall  be  entirely  under  Radar  control.  In 
consequence.  Its  absolute  value  shall  be  regarded  by  the  DPS  as  arbitrary.  The 
Radar  shall  reset  the  clock  within  TBS  milliseconds  of  startup,  and  shall  not 
again  reset  it  during  the  engagement. 
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3.2.10  Miscellaneous  Requirements 

a.  Negative  numbers  crossing  the  interface  shall  be  represented  in 
two's  complement  form. 

b.  Radar  coordinates  shall  be  defined  in  accordance  with  Figure  F-9. 
3.3  DATA  REQUIREMENTS  AND  FORMATS 

TBS 

Data  requirements  and  formats  have  been  defined  for  TDPt  and  that 
definition  might  be  carried  over  to  the  present  document.  However ,  it  is 
not  characteristic  of  systems  such  as  TLS  that  details  of  bit  positions , 
message  formats,  etc.,  would  be  known  at  this  stage  of  development.  However, 
the  dynamic  range,  units,  and  least  significant  bit  information  is  necessary 
in  order  to  write  performance  requirements  on  radar  command  generation.  The 
formats  identification  can  be  postponed  until  process  design  time. 
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Figure  F-9  Radar  Coordinate  System 


1.0  SCOPE 


This  specification  defines  the  physical  and  functional  interface  between 
the  Command  and  Communications  (C  )  System  and  the  Data  Processing  Subsystem 
(DPS)  of  the  Track  Loop  System  (TLS).  The  TLS  itself  is  a  testbed  derived 
from  a  Preliminary  Ballistic  Missile  Defense  System  (PBMUS),  which  is  in  turn 
a  representative  but  unreal  environment  for  these  studies.  TLS  is  intended 
to  have  development  and  test  capability,  although  realization  of  that 
capacity  in  actual  testing  is  not  now  contemplated. 

This  specification  corresponds  to  one  which  would  be  available  prior  to 
preparation  of  a  PPR.  To  that  endt  its  contents  have  been  extracted  from  TDP 
documentation.  Reference  is  made  to  that  material  as  the  source  from  which 
data  here  labeled  "TBS"  and  " TBD "  will  be  derived.  In  this  publication ,  "TBS" 
is  used  to  identify  material  expected  to  be  required  during  early  stages  of 
PPR  preparation,  while  ''TBD"  denotes  material  which  may  be  supplied •  later  in 
the  Specification  process.  Material  presented  in  italics ,  3uch  as  this 
paragraph ,  is  illustrative  or  informative  in  nature,  and  would  not  normally 
appear  in  such  a  specification. 

Some  of  the  paragraphs  in  this  Interface  Specification  place  constraints 
or  requirements  on  the  DPS ;  these  have  been  identified  by  a  *  in  front  of 
that  paragraph. 


2.0  APPLICABLE  DOCUMENTS 


I 

2.1  TLS  SYSTEM  REQUIREMENTS  27332-6921-011.  PART  I.  SECTION  1.1 

2.2  TLS  DATA  PROCESSING  SUBSYSTEM  PERFORMANCE  REQUIREMENTS  (DPSPR> 

27332-6921-011,  PART  II 

2.3  TLS  RADAR/DCS  INTERFACE  SPECIFICATION 

2.4  TLS  ENVIRONMENT  AND  THREAT  MOOEL  DEFINITION 
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3.0  INTERFACE  REQUIREMENTS 


3.1  PHYSICAL  INTERFACE 

TBO 

The  physical  interface  between  the  and  the  DPS  is  entirely  dependent 
on  hardware  selection.  It  will  define  polarity  conventions ,  signal  levels, 
and  related  parameters  of  interest  only  following  PDR,  and  accountable  only 
from  the  time  of  hardware  integration.  Although  this  section  is  required  in 
such  an  interface  specification,  it  will  normally  remain  undetermined  throughout 
the  early  stages  of  software  design. 

3.2  FUNCTIONAL  INTERFACE 

2 

The  functional  interface  between  the  C  and  the  UPS  shall  consist  of 

2 

messages  of  four  types  transmitted  from  the  C  to  the  OPS. 

•  Initiate  Engagement  Mode 
c  Terminate  Engagement  Mode 

•  Handover  Image 

•  Drop  Image  Track 

3.2.1  Initiate  Engagement  Mode 

*  a.  The  DPS  shall  accept  an  Initiate  Engagement  Mode  message  from  any  of 
the  following  prior  modes  of  the  DPS:  TDD.  . 

b.  The  DPS  shall  be  prepared  to  accept  a  Handover  Image  message  within 
TBS  seconds  of  appearance  of  the  Initiate  Engagement  Mode  message  at  the 
Interface. 

3.2.2  Terminate  Engagement  Mode 

a.  The  DPS  shall  accept  a  Terminate  Engagement  Mode  message  at  any 
time  when  It  is  in  Engagement  Mode.  The  DPS  shall  transition  to  TBD  mode  in 
response  to  a  Terminate  Engagement  Mode  message. 

b.  The  DPS  shall  command  no  Radar  transmission  with  an  execution  time 
more  than  TBS  milliseconds  following  appearance  of  a  Terminate  Engagement  Mode 
message  at  the  Interface. 
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3.2.3  Handover  Image 


a.  The  contents  of  the  Handover  Image  message  shall  be 

Image  designation 
Image  estimated  state 
TBS 

2 

b.  The  C  shall  transmit  no  Handover  Image  .message  except  when  the  DPS 
has  been  placed  In  the  Engagement  Mode  by  transmission  of  an  Initiate  Engage¬ 
ment  Mode  message  at  least  TBS  milliseconds  earlier,  and  since  the  last 
Terminate  Engagement  Mode  message. 

3.2.4  Drop  Image  Track 

a.  The  contents  of  the  Drop  Image  Track  message  shall  be  the  image 
designator. 

2 

b.  The  C  shall  transmit  no  Drop  Image  Track  message  for  an  image  designator 
unless  that  designator  was  previously  Included  In  a  Handover  Image  message. 

3.2.5  Message  Acknowledgement 

TBS 

3.2.6  Error  Handling 
TBS 

3.3  DATA  REQUIREMENTS  AND  FORMATS 
TBD 

Data  requirements  and  formats  have  been  defined  for  TDP,  and  that 
definition  might  be  carried  over  to  the' present  document.  It  is  not 
characteristic  of  systems  such  as  TLS  that  details  of  bit  positions ,  message 
formats,  etc.,  would  be  known  at  this  stage  of  development.  However,  the 
dynamic  range,  units,  and  least  significant  bit  information  is  necessary 
in  order  to  write  performance  requirements  on  the  radar  cormard  generation. 

The  formats  identification  can  be  postponed  until  process  design  time. 
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